2,000 Greater & Lesser Mysteries/2,000 Greater and Lesser Mysteries.iso/computer/virus/mys00504.txt

Text File | 1994-06-10 | 3.3 MB | 80,395 lines

VIRUS-L Digest   Wednesday, 12 Jun 1991    Volume 4 : Issue 101

Today's Topics:

Infected networks (PC)
Economic Impact Of Viruses
stoned/NDD (PC)
Re: Hoffman Summary & FPROT (PC)
Is This A Virus? (PC)
Re: Questions about "Disinfectant" (Mac).
Re: Help to remove Joshi from partion table (PC)
MIBSRV file listing - June 11, 1991 (PC)
Re: What is DOD?
CCCP Virus (Amiga)
Boot sector viruses on IDE drives
RE: Frisk's comment in V4 #99 on 'The Bulgarian Menace'
Virus scaners (PC)
Protection evaluation with test virus: (PC)
Re: MS-DOS in ROM (PC)
Help to remove Joshi from partion table (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Tue, 11 Jun 91 10:52:14 -0400
From:    [e-mail] (A. Padgett Peterson)
Subject: Infected networks (PC)

Last week I had occasion to disinfect another large network with the
Jerusalem (not ours - an outside company). The traditional respons is
to take down the net, clean the server, and check all of the clients
before reconnection.  On reflection, this seemed inordinately
inefficient so I came up with a new methodology which I offer for
comment. Note: this works for Jerusalem, Sunday, and non-stealth
infections which infect an executable before allowing it to run -
please be aware of this limitation up front.

The method was as follows:
a) take down net & clean server
b) remove non-essential applications
c) replace essential applications with a batch file that
   1) copies a clean selfcheck program from a writelocked directory
   2) runs the self check program
   3) runs the requested application

In this case I had such a self-check program (1400 bytes) that just
checks its own length & checksum. If it passes, the program exits, if
it fails, the client machine displays a warning message and is locked
up. In this manner, the server application files are protected from
infection (are never called by an infected client). Each client gets a
new copy of the "goat" file so clean clients are not affected, and
infected clients are identified.

Admittedly, this is a special case and directed to a small number of
viruses, but they seem to be the most common.

Comments ?
                Warmly,
                        Padgett

------------------------------

Date:    Tue, 11 Jun 91 16:23:49 -0500
From:    Juan Jose Perez Bueno <[e-mail]>
Subject: Economic Impact Of Viruses

 We need information about the economic impact of viruses around the
world. Particulary damages produced to companies and/or users in
Europe and U.S.A. We prefer information about lost job hours for
viruses.

 Please e-mail me directly. I{ll summarize to the list.

   Thanks in advance

************************************************
*  ___________  Juan Jose Perez Bueno          *
* l_          l Servicio de Informatica        *
*   l         l Universidad Autonoma de Madrid *
*   l   o    /  Ctra de Colmenar Km. 15        *
*   <       l   28049 Madrid (SPAIN)           *
*   l_  ___/    Phone: [phone]         *
*     l/        E-Mail: <[e-mail]>   *
*                       <JJPEREZ@EMDUAM11>     *
************************************************

------------------------------

Date:    Tue, 11 Jun 91 08:39:16 -0700
From:    [e-mail]
Subject: stoned/NDD (PC)

In a note stamped: Mon, 10 Jun 91 19:50:52 -0700, Rob Slade suggests:

=-=-=-=
A number of viral programs would fit this bill, the most obvious being
the ubiquitous "Stoned".  Check the boot sectors of your boot disks with
your Norton utilities.
=-=-=-="

OUCH! I've had many reports that this is the best way to scramble the
content of the disk, depending on what version of NDD you're using. Be
careful on this one, Stan Orrel!

Eric Florack:Wbst311:Xerox

------------------------------

Date:    Tue, 11 Jun 91 10:07:41 -0600
From:    [e-mail] (Richard W Travsky)
Subject: Re: Hoffman Summary & FPROT (PC)

Ray Mann [[e-mail]] writes:
> Richard Travsky was asking how come Patricia Hoffman's Virus Summaries
> keep making reference to only a very old and outdated version of
> F-PROT (v1.07), where the current version is v1.15, going for 1.16 and
> into v2.0 very soon:
>
> > Any reason why such an old version is used?
>
> My suspicion is that this is probably a result of some antagonism
> between Grisk and McAfee, whom Patricia Hoffman follows so closely.
> Frisk is a competitor...

_*IF*_ this is the case, then I would hate to see things take such a
turn as "manipulating" the summary so as to make one package or
another look good or bad.  Once it is done to one package, what is to
stop it form happening to another?  And another?  Will any package
that offends be "punished" by making reference to old and less capable
versions?  (Or "punished" in some other manner?)

The summary is an informative and valuable compilation of virus data.
We users can only lose by seeing it prejudiced by mere commercial
concerns.  Must I be reduced to viewing the summary with a grain of
salt?

Richard Travsky
Division of Information Technology     RTRAVSKY @ CORRAL.UWYO.EDU
University of Wyoming                  (307) 766 - 3663 / 3668

------------------------------

Date:    Tue, 11 Jun 91 19:13:46 +0000
From:    [e-mail] (Greg Burlile)
Subject: Is This A Virus? (PC)

Recently our department has had some problems with all of the files in
the root directory being erased (even the hidden system files).  This
happened about a week ago to one of our PCs and to two of our PCs
today!  I used the files that come with F-PROT that is site licensed
here and could not find anything (F-PROT version 1.13).  Is this a
virus?  I would appreciate any suggestions.  Help!

------------------------------

Date:    11 Jun 91 19:36:40 +0000
From:    [e-mail]
Subject: Re: Questions about "Disinfectant" (Mac).

[e-mail] writes:
>I've been using Disinfectant since version 1.6 and I've had a few
>questions I've wanted to ask for quite a while.
>
>1.  I believe since version 2.0, Disinfectant had the ability to install
>    a protection INIT.  The thing is only 5k... What does it DO?...
>    Does it just give a warning if something is being infected?
>    What does it look for?

I'm not John Norstadt, but I have seen the INIT function when I tried
to run an infected program.  It displayed a dialog box stating that
the application was infected and that I should run Disinfectant to get
rid of the virus.  The application never was started and it went back
to the Finder.

>2.  I remember hearing that using Disinfectant AND the old virus protection
>    CDEV(?) "Vaccine (TM) 1.0.1" was a bad idea (Vaccine somehow rendered the
>    Disinfectant INIT useless or something to that effect).
>      Is it also a good idea to remove the INITs "KillVirus" (Icon is a
>    needle with the word nVIR next to it). and "Kill WDEF - virus INIT"
>    (Icon is just a standard document icon)?  I know these are pretty old
>    too.  (at least I don't have "Ferret" and "Kill Scores" and those other
>    related relics)

I have not experienced these problems.  The only virus protection/eradication
we use in our student labs is Disinfectant 2.4 (and INIT) and Gatekeeper Aid
1.1.  Gatekeeper Aid automatically removes WDEF A.

>2a. Almost forgot... What about "SAM (TM) Intercept" INIT... I know it's
>    newer but do "SAM" and "Disinfectant" interfere with each other?

I have had no problems with Disinfectant and Gatekeeper Aid, and see no
reason to go through the expense of SAM with all of this good, FREE stuff.

>
>My current version of Disinfectant is 2.4... Is this the most current
>one?  I've had it for about 6 months now.

Yes, it's the most current version.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Edwin J. (Ed) Bates            MADVAX Administrator/Postmaster
 Technical Support Specialist        Internet:  [e-mail]
 Office of Information Technology    AppleLink: U1441
 University of the Pacific        Telephone: [phone]
 Stockton, CA  95211            Fax:       [phone]

------------------------------

Date:    Tue, 11 Jun 91 19:49:42 +0000
From:    [e-mail] (Paul McGuire)
Subject: Re: Help to remove Joshi from partion table (PC)

[e-mail] writes:
>I try to use clean77 to remove , i get the virus removed i run the
>computer from new dos after i put the power off when i started ifined
>it again any help appreciation
>
> Terry  jawberh

You should examine the boot sector and see what else you can find.  My
symptoms were that I couldn't boot from the hard disk, and I found
that I had been hit with Joshi and Stoned at the same time, and
neither clean77 nor f-disinf (1.15) fixed it, though they both claimed
that they had.  (Immediately rerunning the respective program told me
I was cured again.)

I wound up doing a low level format, since I wasn't able to find a
clean copy of the boot sector stashed away by either of them, and
wasn't sure of what I was doing anyway.

General question: Is there some way of rewriting the boot record
without doing a low level format, or using a disk editor or debugger?
For that matter, what does one use to do a low level format?  Real
IBMs don't come with low level formatting software.

Paul McGuire
Yale Economic Growth Center

------------------------------

Date:    Tue, 11 Jun 91 14:35:28 -0500
From:    James Ford <[e-mail]>
Subject: MIBSRV file listing - June 11, 1991 (PC)

Here is a listing of files available on MIBSRV as of June 11, 1991.
Please inform me of any outdated files you see on this list.

James Ford - [e-mail]

============================= cut here ===================================
00uploads/     innoc5.zip     uudecode.bas   vcheck11.zip   vsum9105.txt
0REVIEWS/      m-disk.zip     uudecode.doc   vcopy77.zip    vsum9105.zip
0files.9106    navupd01.zip   uudecode.pas   vdetect.zip    vtac48.zip
INDEX.291      netscn77.zip   uuencode.pas   virpres.zip    wp-hdisk.zip
MsDosVir.291   pcvi4.zip      uxencode.pas   virsimul.zip   xxdecode.bas
MsDosVir.690   pkz110eu.exe   vacbrain.zip   virstop.zip    xxdecode.c
MsDosVir.790   scanv77.zip    vaccine.zip    virusck.zip    xxencode.c
avs_e224.zip   secur222.zip   vaccinea.zip   virusgrd.zip   xxencode.cms
clean77.zip    sentry02.zip   validat3.zip   vkill10.zip    zzap54a.zip
fp-115a.zip    trapdisk.zip   validate.crc   vshell10.zip
fshld15.zip    unvir902.zip   vc140cga.zip   vshld77.zip
htscan12.zip   uu-help.text   vc200ega.zip   vstop54.zip

------------------------------

Date:    Tue, 11 Jun 91 20:24:53 +0000
From:    [e-mail] (Anup C. Patel)
Subject: Re: What is DOD?

[e-mail] (John M Twilley) writes:
>[e-mail] (Mac Su-Cheong) writes:
>
>>  May someone please give me information on DOD Computer Security Center ?
>>Is it possible to get reports or papers of DOD ?
>
>DOD stands for the United States Department of Defense.
>
>I am pretty sure that they publish unclassified information on
>virii, but I wouldn't know where to find it.

These are some of the documents I received from the NCSC (National
Computer Security Center) several years ago.  More info on NCSC
follows.  If anyone wants to contact the NCSA, I could dig up their
phone number.  Most of the documents listed below are at least 4-6
years old.

Department of Defense (DOD) documents:
======================================
"Department of Defense Standard: Department of Defense Trusted Copmuter
                                System Evaluation Criteria"

"Department of Defense: Password Management Guideline"

"Computer Security Requirements:  Guidance for Applying the Department of

                                 Defense Trusted Computer System Evaluation
                                 Criteria in Specific Environments"

"Technical Rational Behind CSC-STD-003-085 (see above): Computer Security
Requirements "


National Security Agency (NSA) documents:
=========================================
"Information Systems Security: Products and Services Catalogue"

"Computer Security Subsystem: Interpretation of the Trusted Computer System
                             Evaluation Criteria"

"Trusted Network Interpretation of the Trusted Computer System Evaluation
Criteria"

"Design Documentation in Trusted Systems"

"Configuration Management in Trusted Systems"

"Glossary of Computer Security Terms"

"Discretionary Access Control in Trusted Systems"

"A Guide to Understanding Audit in Trusted Systems"

"Personal Computer Security Considerations"





****************************  Reprinted from the ****************************
****************************  Computer Library   ****************************

Book:      The Computer Glossary  (The Electronic Version)
           * Full Text COPYRIGHT The Computer Language Co. Inc. 1990.
- -----------------------------------------------------------------------------
Term:      NCSC
Author:    Freedman, Alan.
- -----------------------------------------------------------------------------

(National Computer Security Center)  An arm of the U.S. National Security
Agency that defines criteria for trusted computer products.  The security
levels in its Orange Book (Trusted Computer Systems Evaluation Criteria, DOD
Standard 5200.28) follow.  Each level adds more features and requirements.

   D  - Non-secure system.

Level C provides discretionary control.  The owner of the data can determine
who has access to it.

   C1 - Requires user log-on, but allows group ID.

   C2 - Requires individual user log-on with
        password and an audit mechanism.

Levels B and A provide mandatory control.  Access is based on standard DOD
clearances.

   B1 - DOD clearance levels.
   B2 - Guarantees path between user and the
        security system.  Provides assurances that
        system can be tested and clearances cannot
        be downgraded.

   B3 - System is characterized by a mathematical
        model that must be viable.

   A1 - System is characterized by a mathematical
        model that can be proven.  Highest
        security.

- -----------------------   End of Document ----------------------

------------------------------

Date:    11 Jun 91 17:14:59 +0000
From:    Tom Carter <[e-mail]>
Subject: CCCP Virus (Amiga)

Recently discovered the CCCP virus on one of my disks on 4 files. I am
unfamiliar with this virus but was able to detect and (I hope)
eradicate it by deleting the infected files and re-installing them off
my WB disk. Can some virus wizard tell me about this virus and what it
does? How bad is it?

Also had Smily Cancer Virus a while back and thanks to advice found
here, used MVK to get rid of that. Are there any other Virus
Killer/Checkers which will detect SC? Thanx.

------------------------------

Date:    Tue, 11 Jun 91 11:00:33
From:    [e-mail] (John Boyd;LAHDI)
Subject: Boot sector viruses on IDE drives

It recently occurred to me that we get rid of most boot-sector viruses
by routinely doing a low-level format on a drive.  However, this is
not possible on an IDE drive.  So the question becomes; for an IDE
drive, what DO you do to get rid of a boot sector virus?  And yes, I
am constantly telling the users that I support that they really should
be scanning everything first; even before doing a directory, and all
the other prudent precautionary steps, so hopefully we won't have a
problem, but you know how that works.
- ------------------------------------------------------------------------
Text contained herein is my personal opinion.  This is not to be
interpreted in any way as a position or statement of the DOD, USAF, or any
other person or entity other than myself.

------------------------------

Date:    Tue, 11 Jun 91 11:54:03 -0400
From:    "Richard Budd" <[e-mail]>
Subject: RE: Frisk's comment in V4 #99 on 'The Bulgarian Menace'

 Juergen Olsen writes in VIRUS-L Digest V4 #100:

 > How about making the thing political?  If 'certain countries' expect
 > 'other countries' - e.g. (ours) to financially bail them out of up to
 > 74 years of infrastructural mismanagement we could at least demand
 > that the kill of their virus factories before we open our purses!!

 To take a page out of the computer underground, wouldn't it be more
 productive to incorporate these ' virus factories ' as part of
 the research into computer viruses.  It could become both a source of
 income for nations like Bulgaria and a source of employment for bored
 or out-of-work programmers.
=========================================================================
 Richard Budd               | Internet: [e-mail]
 VM Systems Programmer      | Bitnet  : [e-mail]
 IBM - Sterling Forest, NY  | Phone   : [phone]
=========================================================================

------------------------------

Date:    Tue, 11 Jun 91 11:32:00 -0500
From:    <[e-mail]>
Subject: Virus scaners (PC)

My PC was in the repair shop and I got a call from the guy there
stating that there is a virus on my hard drive.  I do not know what
kind of virus it is.  Can someone recomend a good virus scanner I can
use to remove this virus.

Thanks

- -Payam

[e-mail]

------------------------------

Date:    11 Jun 91 21:45:13 +0000
From:    Dennis Hollingworth <[e-mail]>
Subject: Protection evaluation with test virus: (PC)

(PC) Protection evaluation with test virus.

Posted for Dan Hirsh [phone]

I tested McAfee's SCAN77 using Rosenthal Engineering's new release of
Virus Simulator (I've seen posted as VIRSIM11.COM on EXEC-PC,
Compuserve and others).  It seems that SCAN77 misses three boot sector
viruses that SCAN76 found on the same disk.  Both versions of SCAN
found nine viruses in the .COM, four in the .EXE and seven in the test
memory virus.

THESCAN, F-FCHK and VIRX also found the test viruses, but Norton's
Anti Virus couldn't find anything.

There's been a number of postings about scanner producers bragging
that their scanners search for more viruses than the next guys.  Well,
it's not how many viruses your scanner looks for that counts.... It's
how many you can find!

------------------------------

Date:    Tue, 11 Jun 91 21:10:44 -0700
From:    [e-mail] (Jesse Chisholm AAC-RJesseD)
Subject: Re: MS-DOS in ROM (PC)

[e-mail] (Padgett Peterson) writes:
| "William Walker C60223 x4570" <[e-mail]> writes:
|
| >We're writing from two different premises.  Padgett is writing about
| >MS- DOS actually running from ROM, while I'm writing about the DOS
| >files, and the boot disk itself, being in ROM ( a ROM-disk, as opposed
| >to a RAM-disk ).  ... The method of booting from
| >a ROM- disk ( with an infection-proof boot sector and system files ),
| >which I wrote about, is not implemented at this time, to the best of
| >my knowledge.

Acer America in joint venture with Smith Corona has recently marketed
a small 286 PC that has a ROM cartridge that is used as a ROM disk.
SCC sells it as a PWP-100 (Personal Word Processor) and the software
looks alot like their earlier WP machines.  This is the first in a
product line that has MS-DOS on ROM cartridge.  Not all of DOS, just
enough to boot. (IO.SYS, MSDOS.SYS, COMMAND.COM, AUTOEXEC.BAT,
CONFIG.SYS, and maybe SHARE.EXE, HIMEM.SYS, ANSI.SYS, ..., and the WP
software)

| While I follow the premise better now, what you are talking about is
| what I referred to in the third option - somehow swapping ROM
| addresses for RAM addresses or possibly a "page frame" approach such
| as used for expanded memory. It will take a special BIOS driver to
| accomodate just like a RAM-disk requires a special driver and the data
| areas will have to stay resident somewhere. The point is that there
| are a finite number of addresses available and if some are used for
| ROM then there are that many less for RAM unless some extra memory
| management scheme is used such as that used for "shadow RAM" on 386s -
| not difficult but requires a few extras.

Acer's method doesn't use up RAM addresses, since the ROM card is seen
as a read-only hard disk.  The ROM card itself does use some IOcard
address space since it is considered an expansion card by the
hardware.

| The point I was trying to make was that even with this type of
| mechanism, the same holes exist in MS-DOS as did before. Some have
| been moved (e.g.  the first attackable point) so that specific
| malicious software will be thwarted, but the hole still exists and
| will just be exploited in the next crop. There is still NO integrity
| management in MS-DOS.

Sad but true.

Jesse Chisholm          | Disclaimer: My opinions are rarely understood, let
[e-mail] | tel: [phone] | alone held, by this company.
[e-mail]   | fax: [phone] |-----------------------------
======== This company has officially disavowed all knowledge of my opinions.
- --
"Question Authority!"  -- Wallace Stegner
"And that's an order!"

------------------------------

Date:    Tue, 11 Jun 91 23:24:55 -0700
From:    [e-mail] (Rob Slade)
Subject: Help to remove Joshi from partion table (PC)

[e-mail] writes:

> I try to use clean77 to remove , i get the virus removed i run the
> computer from new dos after i put the power off when i started ifined
> it again any help appreciation
>
>  Terry  jawberh
> [e-mail]

I would suggest a slight reordering of your disinfection procedure.

     1) Boot from a known, clean, write protected system floppy disk.
     2) Then run CLEAN/FPROT/whatever to remove the infection.
     3) Test your system again, and redo if necessary.
     4)  Reboot.


=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 101]
******************************************
VIRUS-L Digest   Thursday, 13 Jun 1991    Volume 4 : Issue 102

Today's Topics:

Re: Questions about "Disinfectant" (Mac).
Virus detection & removal (PC)
Possible Virus? (PC)
Re: Removing Azusa (was: Hong Kong on...) (PC)
Dave Barry's definition of a computer virus
Re: Is there a 1024 virus? (PC)
Re: Hypercard Antiviral Script? (Mac)
F-PROT 1.16 (PC)
Re: Protection evaluation with test virus: (PC)
Is there a 1024 virus? (PC)
Re: Hypercard Antiviral Script? (Mac)
Ws and Ps now you see em.... (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Wed, 12 Jun 91 03:22:00 -0500
From:    Big fish man on hippocampus <[e-mail]>
Subject: Re: Questions about "Disinfectant" (Mac).

[e-mail] writes:
> I've been using Disinfectant since version 1.6 and I've had a few
> questions I've wanted to ask for quite a while.
>
> 1.  I believe since version 2.0, Disinfectant had the ability to install
>     a protection INIT.  The thing is only 5k... What does it DO?...
>     Does it just give a warning if something is being infected?
>     What does it look for?

If the virus is in an application, the an alert is displayed saying
Disinfectant INIT found a virus and that it should be removed with
Disinfectant.  It will not let the program run.  If the virus is in
the Desktop, a similar alert will be shown, the Finder will run, but
the virus will be "contained," kept from furthering the infection.

This INIT only checks applications when they are run and do not check
documents (i.e. Hypercard stacks).

>
> My current version of Disinfectant is 2.4... Is this the most current
> one?  I've had it for about 6 months now.

As far as I know...

- --
           |\   \\\\__       Tony Maimer                __
           | \_/    o \                                /  |
            > _   (( <_                               /   |
           | / \__+___/  [e-mail]   /o   /_/|
           |/     |/                                <  ))  _ <
                                                    \     \ \|
                                                     \    |
       +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

------------------------------

Date:    Wed, 12 Jun 91 09:30:56 -0400
From:    [e-mail] (A. Padgett Peterson)
Subject: Virus detection & removal (PC)

>Just that our experience that I wished to share was that with a
>checksummer in place and use of SCAN, you can end up with every last
>EXE/COM file on you hard disk looking very sick indeed.

>Mike Lawrie
>Director Computing Services, Rhodes University, South Africa
>....................<[e-mail]>..........................

I agree, such activity is possible which is why I recommend that techs
be properly trained (ours get two full days) before being allowed to
work on suspected viruses. CHKDSK & DEBUG anre powerful tools in
trained hands as are MANIFEST, MEM, & MAPMEM. Scanners are very good
automated tools for problems they hve seen before and can take care of
98% of our problems: the other 2% just have to be handled manually -
see below

- --------------------------------------------------------------------

>From:    [e-mail] (Derek William Ebdon)
>Subject: Re: Hong Kong on MircoTough dist. disks (PC)

>One thing that Mr. Doss forgot to mention is that although Central
>Point Anti-Virus v1.0 can easily romove the Asuza virus from a floppy,
>it cannot remove the virus from a hard drive.  The only way to
>disinfect a hard drive is to redo the low level format because the
>virus infects the boot sector and the dos partition.  A high level
>format will not remove the virus, nor will simply removing the dos
>partition with the fdisk program.

NO, NO, a thousand times NO !I have never seen an infection that
requires low level formatting (besides, on some newer disks you can't)
Azusa is one of the easier to remove (believe I posed instructions
some time ago) - certainly easier than the MusicBug which can also be
removed. If the problem is understood, formatting is never necessary.
Azusa can be removed just using debug if you know what you are doing.
Just because one generic tool does not know how to do it does not mean
it cannot be done.

                    Warmly,
                            Padgett

------------------------------

Date:    Wed, 12 Jun 91 11:02:12 -0400
From:    [e-mail] (R. B. Evans)
Subject: Possible Virus? (PC)

I have a Packard Bell 286 with the following problem:

Every once in a while (50-300 characters typed) a character typed at
the keyboard doesn't seem to *make-it* to the PC, and instead produces
an audible beep.  In addition, the keyboard occasionally shifts into a
mode where the SHIFT key is being held down, (types !@# instead of
123), but the shift key has not been hit, so is not physically
sticking.

Packard Bell Technical Support has been unable to fix the problem.
They have replaced three keyboards, two motherboards, and one power
supply in their *troubleshooting* efforts.  With all this hardware
replaced, I suspect a possible virus, but Scan V77 shows no viruses
found.

If anyone has any ideas as to how to fix this annoying problem, please
E-mail me your suggestions/ideas.

Thanks in advance,

Robert Evans
[e-mail]

------------------------------

Date:    12 Jun 91 11:12:51 -0400
From:    "David.M.Chess" <[e-mail]>
Subject: Re: Removing Azusa (was: Hong Kong on...) (PC)

>From:    [e-mail] (Derek William Ebdon)
>The only way to
>disinfect a hard drive is to redo the low level format because the
>virus infects the boot sector and the dos partition.

A low-level format is certainly not the *only* way to fix an
Azusa-infected hard disk.  Any program that can write a valid boot
record to the partition-table area (preserving the partition
information and just fixing the code) will remove the virus from the
execution stream, and (since the Azusa uses only the partition table
area on a hard disk, and no sectors in the DOS partition or anywhere
else) that will disinfect the disk very nicely...  DC

------------------------------

Date:    Wed, 12 Jun 91 11:47:33 -0400
From:    Joe McMahon <[e-mail]>
Subject: Dave Barry's definition of a computer virus

Dave Barry's column in the Sunday Washington Post, "Our Friend the
Computer", has the following defintion of a computer virus:

     "...You have probably read about computer viruses, which
      computers get when they're left uncovered in drafty rooms.
      This is bad, because if you're working on an infected
      computer, it will periodically emit electronic sneezes
      (unfortunately not detectable with the naked eye) and
      you'll be showered with billions of tiny invisible pieces
      of electronic phlegm, called "bytes", which penetrate into
      your brain and gradually make you stupid..."

 --- Joe M.

------------------------------

Date:    12 Jun 91 17:28:33 +0000
From:    [e-mail] (Chris Maslyar)
Subject: Re: Is there a 1024 virus? (PC)

>> Can anyone suggest an explanation of our observation on several
>> computers (various IBM pc types) of a result from chkdsk of 654336
>> bytes of total memory?

>A number of viral programs would fit this bill, the most obvious being
>the ubiquitous "Stoned".  Check the boot sectors of your boot disks with
>your Norton utilities.

I noticed this 654336 anomaly as well.  Unfortunately (fortunately?)
SCAN V7.2V77 didn't find a culprit, and Norton utilities came up blank
when I searched for "Stoned".  I'll spare you the details of the painful
steps taken to arrive at my solution to say that:

    Some PC/AT computers give the user an option to place 1K of BIOS
    into base memory subsequently reducing the size of memory to:

    (you guessed it)  654336

You may want to look for this option BEFORE you format your disks :)

Good Luck

Chris
[e-mail]

------------------------------

Date:    Wed, 12 Jun 91 19:31:35 +0000
From:    [e-mail]
Subject: Re: Hypercard Antiviral Script? (Mac)

Your best defense is locking your home stack, or constantly searching
your home stack for script modifications.

You can try editing the script of a stack before opening it, but the
virus might be in any object in the new stack.

Even though you can check the params of a set command for the word
"script", no unlocked stack will be safe until Apple prevents using
the set command in a end to HyperCard

I'd elaborate, but wouldn't feel right about explaining how to commit
sabotage.

- --Eric

------------------------------

Date:    Wed, 12 Jun 91 23:23:11 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: F-PROT 1.16 (PC)

Well - F-PROT 1.16 is out...It was delayed a bit, as unusually many viruses
have arrived in the past three weeks...

Version 1.16 added the following features:

        Detection, but not disinfection of 27 new viruses:

        200
        268-plus
                483
        Bad Boy
        Cascade - 2 new variants: Formiche and JoJo-1703
        Darth Vader (4 variants)
                Diamond - 4 new variants: Damage, Damage-B, David and Greemlin
        Eddie - new variant: MIR
         Fingers 08/15
        Hero
        Leech
        Murphy - 4 variants: Cemetery, Kamasya, Migram-1 and Migram-2
        Stardot
        Swiss-143
        VCS 1.0
        Warrior
        Witcode

    Detection and removal of 85 new viruses:

        1024-PrScr
                1575-B (alias 'Greencat-2')
        Backtime
        Bljec - 7 variants: Bljec-3, Blec-4, Bljec-5, Bljec-6,
            Bljec-7, Bljec-8, Bljec-9
        Boys
        CARA
         Casino
                Cinderella
                Demon (overwriting)
        Diamond - new variant: Lucifer
        Eddie - 4 new variants: 1028, 1801, Apocalypse-2 and Zeleng
        ETC
                Frog
        Horse (alias 'Naughty Hacker') - 8 variants: Horse-1, Horse-2,
            Horse-2B, Horse-3, Horse-4, Horse-5, Horse-6, Horse-7
                Incom
        Jerusalem - 6 new variants: Apocalypse, Carfield, Discom,
            GP1, Phenome and Skism
        Keypress-1228
         Kiev-483
        Little Pieces
        Magnitogorsk - new variant: 2048
        MG - new variant: MG-1A
        Minimal-30
        Murphy - 11 new variants: AntiChrist, Diabolik, Erasmus,
            Finger, Goblin, Guru, Murphy-3, Murphy-4, Pest,
            Smack-1835 and Smack-1841
        Mutant - 3 variants
        Old Yankee - new variant: Bandit
        PcVrsDs
        Pixel - 11 new variants: 257, 275, 283, 295, 779, 837,
            850, 854, 877, 892, 936
                Raubkopi
        Sparse
         Striker #1
        Sylvia-B (previously identified as Sylvia)
        Tequila
                Tumen - 2 variants: 0.5 and 2.0
         USSR-311
                Vienna - 2 new variants: Arf and Vienna-645
        WWT - 2 variants: WWT-01 and WWT-02 (overwriting)
           Yaunch (alias 'Wench')
        Yukon (overwriting)
        ZK-900

    Disinfection of the following viruses, which were detected in
    earlier versions:

        Faust (alias Chaos) (previously called 'Spyer')
        Form

    The following names have been changed, in an attempt to reduce
    the incredible confusion in the virus naming area.

        1075 --> DBF blank
        June 4th --> Bloody!
                Spyer --> Faust
        Turku --> Keypress

    The following bugs/problems have been fixed:

        The signature for the 1049 virus has been changed, as it
        could cause false alarm in the 386COM.SYS file.

        F-FCHK would not detect all the possible mutations of
        the Whale virus in .COM files, although all infected
        .EXE files were found.  This has been corrected.

        Occasional very long delays when some programs, such as
        SORT.EXE in DOS 4.0 were run have been eliminated.

        F-OSCHK will now correctly handle the case where a
        checksum evaluates to 0, as 0 previously meant "ignore".
        Instead the string ----- is now used when a checksum
        should be ignored.

        When F-DRIVER and F-NET were in use, Novell "execute-only"
        programs could sometimes not be executed.  This has
        been corrected.

        F-DRIVER would on some computers fail to detect some boot
        sector viruses if it was loaded into high memory (above
        640K.  This has been corrected - LOADHI etc should now
        work without problems.

        F-FCHK will now indicate if a program has been compressed by
        DIET 1.10, ICE 1.01 or EXEPACK.  This warning only indicates that
    a virus could possibly have been hidden in the program before it
    was packed - not that anything appears to be wrong.

    A new file has been added with information on Trojans and "Joke"
    programs, often found in virus collections.  Those programs are
    not a threat like viruses - but some of my competitors detect
    them, so....

        /QUERY switch added to F-FCHK.  if it is used, F-FCHK will ask if
    it should disinfect any infected files - this used to be the
    default.

    A conflict has been reported between F-DRIVER and Desqview, and
    I am trying to determine if a problem exists.

- -frisk

------------------------------

Date:    Wed, 12 Jun 91 23:50:07 +0000
From:    [e-mail] (McAfee Associates)
Subject: Re: Protection evaluation with test virus: (PC)

[e-mail] (Dennis Hollingworth) writes:
>Posted for Dan Hirsh [phone]
>
>I tested McAfee's SCAN77 using Rosenthal Engineering's new release of
>Virus Simulator (I've seen posted as VIRSIM11.COM on EXEC-PC,
>Compuserve and others).  It seems that SCAN77 misses three boot sector
>viruses that SCAN76 found on the same disk.  Both versions of SCAN
>found nine viruses in the .COM, four in the .EXE and seven in the test
>memory virus.
[rest of message deleted...]

Rosenthal Engineering's VIRSIM program is a string-based virus
simulator.  As such, only scanners that use the same strings that
VIRSIM uses will detect its "viruses."

We regularly adjust our strings, so this why V76 would report viruses
that V77 did not.

Regards,

Aryeh Goretsky
McAfee Associates Technical Support

- --
McAfee Associates     | Voice [phone]    | [e-mail]
4423 Cheeney Street     | FAX   [phone]    | (Aryeh Goretsky)
Santa Clara, California     | BBS   [phone]    |
95054-0253  USA         | v.32  [phone]    | [e-mail]
ViruScan/CleanUp/VShield | HST   [phone] | (Morgan Schweers)

------------------------------

Date:    12 Jun 91 19:30:42 -0400
From:    Arthur Buslik <[e-mail]>
Subject: Is there a 1024 virus? (PC)

Stan Orrell writes:

 "Can anyone suggest an explanation of our observation on several
 computers (various IBM pc types) of a result from chkdsk of 654336
 bytes of total memory?"

As Rob Slade suggests, one possibility is a virus.  However, a much
more likely possibility is that the computers have extended bios
extended data areas. (See, e.g. "The New Peter Norton Programmer's
Guide to the IBM PC & PS/2",2nd edition, 1988, page 62.)  INT 15H,
AH=C0H will return ES:BX as the segment:offset of a configuration
table.  The fifth byte of this configuration table gives configuration
flags.  Bit 2 of this byte is set if an extended Bios data area is
allocated.  Moreover, INT 15H, AH=C1H will return the segment address
of the base of the extended bios area.  The word at 0040:0013H is
modified to reflect the reduced amount of memory available to
programs.  This is what chkdsk returns as "bytes total memory", and
also what INT 12H returns in AX.  On my COMPAQ 386/20e at work, I
obtain the following when I use DEBUG:

- -a100
1AFA:0100 mov ah,c0
1AFA:0102 int 15
1AFA:0104
- -g104

AX=0000  BX=E6F5  CX=0000  DX=0000  SP=FFEE  BP=0000  SI=0000  DI=0000
DS=1AFA  ES=F000  SS=1AFA  CS=1AFA  IP=0104   NV UP EI PL ZR NA PE NC
1AFA:0104 0000          ADD     [BX+SI],AL                         DS:E6F5=6E
- -df000:e6f5 l 9
F000:E6F0                 08 00 FC-01 00 74 00 00 00              .....t...

The configuration flag byte is 74H=01110100B, and since bit 2 is set, my
machine has an extended bios data area allocated.

Moreover, using DEBUG again, this time for INT 15H, AH=C1H, I obtain:

- -a100
1C6B:0100 mov ah,c1
1C6B:0102 int 15
1C6B:0104
- -g104

AX=C100  BX=0000  CX=0000  DX=0000  SP=FFEE  BP=0000  SI=0000  DI=0000
DS=1C6B  ES=9FC0  SS=1C6B  CS=1C6B  IP=0104   NV UP DI NG NZ AC PO NC
1C6B:0104 7205          JB      010B
- -d9fc0:0
9FC0:0000  01 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
etc., all following bytes being zero.

My machine has 1Kb of memory reserved, at the top of memory for an extended
bios data area.  The first byte gives the number of Kb of memory reserved.
On my machine all the other bytes are zero, whenever I look at them
with DEBUG.  (I don't know what they are when I don't look at them.)
For what it is worth, the machines at work which have the extended bios
data area implemented, and for which chkdsk returns 639K total memory,
all have a socket in the back for a bus mouse.

Art Buslik

------------------------------

Date:    Thu, 13 Jun 91 00:49:47 +0000
From:    [e-mail] (Michael Kerner)
Subject: Re: Hypercard Antiviral Script? (Mac)

I said I was going to rewrite my scripts to handle new trojans/viri,
however I am trying to consider some options.

The main problem is that there is no way to catch the parameters of
the SET function in HC 2.1.  So, while I play with different virus
scenarios (i.e.  writing ones that I think will do certain things,
using certain HC resources, I want to try and find some common link
between them.  The answer, then, will be unable to intercept and stop
infection, but will have to work beforehand.

The problem with this is that a field of all stacks that have been
checked needs to be kept, and everytime that a stack is opened, the
field must be examined to see if this particular stack has been
checked.  However, the problem with that is that existing checked
stacks may have been infected and will thus escape detection.  So,
while my solution appears to be the simplest (i.e. check all stacks to
begin with then keep a running list), the time spent by the user seems
to be very long.  So, the story on this is: unless there seems to be
some need/desire emerge for a new stack/utility to do this work, I'm
moving slowly.  As I said before, if anyone else feels like beating me
to the punch with a solution of their own, feel free - but don't you
DARE charge $$ for it.

Mikey.
Mac Admin
WSOM CSG
CWRU
[e-mail]

------------------------------

Date:    11 Jun 91 21:53:35 +0000
From:    [e-mail] (Ullrich Fischer)
Subject: Ws and Ps now you see em.... (PC)

The following problem has occurred on our network over the past two days:

On Monday, a user showed us two printouts from WordPerfect 5.1
(Network version) printed from the same document about 5 minutes
apart.  She swears she made no changes to the document between the two
printouts.

On one printout all the Bitstream Dutch 11 point (we use Bitstream
fonts on HP Laserjet II printers) 'w's (upper and lower case) were
missing (i.e.  replaced by relatively narrow blank spaces).  On the
2nd printout, the 'w's were all there.  At the top of the document, a
large capital W using a different font appeared in both printouts.  It
is a one-page document.

Today the same sort of thing happened to another user on a different
PC using Lotus 2.01 networker.  This time the 'p's were missing from
one printout but not another of the same spreadsheet.

We are using Novell Netware 2.15C on an internet with a 3.1 server.
These incidents happened to people who were using the 2.15C to store
their data files and the application software.

We are using Printer Assist from Fresh Technologies to print to the
laser printers.  The two incidents involved different printer servers
and printers as well as different PCs.  Both PCs used DOS 3.3

I scanned the network and both PCs involved using McAfee's SCAN
version 77 but turned up no indication of any virus infection.

To the best of my knowledge, this is the first time anything like this
has happened on our network.

No, I am not sure this is a virus, but it seems the kind of thing that
malicious code might do.  If anyone has any ideas as to what may be
going on here, I would be grateful to hear them.

- - Ullrich [e-mail]   (Let's just have 1 line signatures eh?)

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 102]
******************************************
VIRUS-L Digest   Monday, 17 Jun 1991    Volume 4 : Issue 103

Today's Topics:

Re: Hong Kong on MircoTough dist. disks (PC)
re: Is there a 1024 virus? (PC)
DOS 5 Fdisk (PC)
Re: Hypercard Antiviral Script? (Mac)
Request for info on BBS viruses, worms, etc
Possible PC Virus (PC)
Re: Virus scaners (PC)
Re: Help With Frodo & Yankee Doodle (PC)
Infected networks (PC)
Re: Questions about "Disinfectant" (Mac).
Getting register contents, etc. "on the fly." (PC)
Problems removing Azusa (PC)
Re: Is there a 1024 virus? (PC)
Fprot v1.16 (PC)
Why I didn't find the virus.exe (PC)
Re: Hoffman Summary & FPROT (PC)
New address and hostname for MIBSRV (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Thu, 13 Jun 91 11:43:07 -0500
From:    [e-mail] (Frank Doss)
Subject: Re: Hong Kong on MircoTough dist. disks (PC)

[e-mail] (Derek William Ebdon) writes:
>One thing that Mr. Doss forgot to mention is that although Central
> . . .
>it cannot remove the virus from a hard drive.  The only way to
>disinfect a hard drive is to redo the low level format because the

For those of you with IDE hard drives, contact Seagate.  They are
selling Disk Manager (version 4.1 or later is needed) for $6.00.  This
version of Disk Manager will format the boot sector, partition table,
and the data sections of the disk, but not the error table.  You might
want to ask Seagate and your vendors for details.

I am not endorsing Disk Manager, but merely reporting what Mr. Ebdon has
reported as what worked for him.

Thanks, Derek, for the reminder.  I hope your machine is working much
better now.  ;-)

Frank E. Doss
Eastern Illinois University

------------------------------

Date:    Thu, 13 Jun 91 12:52:56 -0400
From:    [e-mail] (A. Padgett Peterson)
Subject: re: Is there a 1024 virus? (PC)

>From:    Arthur Buslik <[e-mail]>
>
>As Rob Slade suggests, one possibility is a virus.  However, a much
>more likely possibility is that the computers have extended bios
>extended data areas.

This is certainly a vialble alternative. However, if running DOS 4.0
or later, CHKDSK will "normally" detect this and return "655360"
anyway.

A few years ago, when we received or first Compaq 386-20e in we
discovered the same thing: 1k missing from the TOM & DEBUG revealed it
to be essentially zero-filled (obviously not executable). After much
prodding, Compaq told us that it was a buffer area for the mouse
driver and that there is a jumper on the motherboard that can be moved
to restore the missing 1k.

Whenever a new machine comes in, it is a good idea to take some
baseline data for later reference.

For me, any time Int 12 is lowered, I check the memory area in
question.  If executable code is found, unless known, a look is taken
at other system integrity areas for a reason. If nulled or obviously
data, the manufacturer is called for an explination (often a
frustating & time consuming experience).

                        Padgett

            Somewhere West of Orlando

------------------------------

Date:    13 Jun 91 14:26:07 -0400
From:    [e-mail]
Subject: DOS 5 Fdisk (PC)

Readers might want to play with an undocumented /MBR switch in DOS 5
FDISK.  It appears to force FDISK to overwrite the code in a PC/PS2
master boot record, without touching the partition table, and in
limited testing on a half dozen machines it succeeded in cleaning up
machines infected with the Stoned, the Stoned 2, and the Joshi
viruses.  This was with the DOS 5 shipped by IBM, not Microsoft's DOS
5; can somebody please test MS-DOS 5?

The Joshi can't be removed this way unless it isn't active in memory.
(e.g. cold boot from a write protected, uninfected bootable DOS 5 disk
with a copy of FDISK on it.)

The command line syntax tested was
   FDISK /MBR

Bill Arnold    [e-mail]

------------------------------

Date:    Thu, 13 Jun 91 18:38:36 +0000
From:    [e-mail]
Subject: Re: Hypercard Antiviral Script? (Mac)

Mike writes...
- ------------------------------------------------------------------
The main problem is that there is no way to catch the parameters of
the SET function in HC 2.1.
- -----------------------------------------------------------------
I write...
According to the release notes, you can catch the parameters of a Set in HC 2.1
But that doesn't matter since a Send to HyperCard is untrappable.

Mike later writes...
- -----------------------------------------------------------------
The problem with this is that a field of all stacks that have been
checked needs to be kept, and everytime that a stack is opened, the
field must be examined to see if this particular stack has been
checked.
- ------------------------------------------------------------------
I write...
Unfortunately if the virus stack traps for the OpenStack Message it becomes
harder to know when a new stack has been opened. You could have the user induce
the checking proceedure, but then it would be too late and your Home Stack
script could be wiped out or other worse things could happen by then.

Mike again....
- --------------------------------------------------------------------
  As I said before, if anyone else feels like beating me
to the punch with a solution of their own, feel free - but don't you
DARE charge $$ for it.
- --------------------------------------------------------------------
Me again...
The only solution seems to be, check your Home Stack periodicaly, or lock it,
and always make backups of important stacks.
Apple MUST prevent using a Set command within a Send to HyperCard or no stack
will be safe!!

Sounds scary doesn't it?

>Mikey.
>Mac Admin
>WSOM CSG
>CWRU
>[e-mail]

 and me...
- --Eric

------------------------------

Date:    Thu, 13 Jun 91 15:33:00 -0500
From:    [e-mail]
Subject: Request for info on BBS viruses, worms, etc

We are putting together a list of viruses, worms, or trojan horses
specifically aimed at BBS software or are capable of being implanted
in a system through BBS procedures (e.g., new user information,
uploading zip files).  We *ARE NOT* looking for viruses that are
spread *on* BBSs by sharing of software, but rather for programs
speficially designed to attack a system *using* BBS software, such as
the recent bug in Telegard that allowed a user to access the system
using zip files.

We are trying to update a story for CuD. Responses can be sent to:
   [e-mail]     or  [e-mail]

Jim Thomas / Sociology-Criminal Justice / Northern Illinois University

------------------------------

Date:    Thu, 13 Jun 91 13:36:04 -0700
From:    "robert c. morales" <[e-mail]>
Subject: Possible PC Virus (PC)

I have a Packard Bell with an 80386X-16 Mhz CPU. It runs on MS-DOS
4.01 and a Dosshell 4.0. Everytime I do work on the computer (word
processing, networking, games, etc.) DOS seems to create (on its own)
a file, named numerically or alpha-numerically but in a random
fashion, of about 15K in size (with a range of from 7K to 17K). When
you try to view the file (which incidentally sits among the DOS
files), you can make out that it is bits and pieces of what is on the
hard drive. Initially, it has not affected any other program on the
hard drive. However, two days ago, the DOS files appeared to have
replicated themselves with such names as EDLIN._OM and AUTOEXEC._AT,
all of which were 77 bytes in size with the same dates and times. This
necessitated reformatting the hard drive. Also, the Dosshell was
removed from the AUTOEXEC.BAT. Right now, the problem seems to have
been corrected, whatever it was. Is anybody familiar with this
problem? Most other resource people I I have consulted about this have
indicated that they have only heard about this on Packard Bell
computers. Any tips?

Robert Morales
7340p@navpgs
[e-mail]

------------------------------

Date:    Wed, 12 Jun 91 23:57:53 -0700
From:    [e-mail]
Subject: Re: Virus scaners (PC)

In a recent VIRUS-L posting Dennis Hollingworth <[e-mail]> said:

 > I tested McAfee's SCAN77 using Rosenthal Engineering's new
 > release of Virus Simulator (I've seen posted as VIRSIM11.COM
 > on EXEC-PC, Compuserve and others).  It seems that SCAN77
 > misses three boot sector viruses that SCAN76 found on
 > the same disk.  Both versions of SCAN found nine viruses
 > in the .COM, four in the .EXE and seven in the test memory
 > virus.

Since no real virus was present all of these "hits" could be regarded
as false alarms, theoretically. We must be careful to distinguish what
is being tested here. Just because a particular anti-viral product
does not declare a particular test string to be a virus, we cannot say
that the scanner has failed. A good case can be made for saying that
the simulator failed.

The only "test target" that can be used is the entirety of a virus,
and at that point you no longer have a "simulator", you have the real
thing.

Fritz Schneider

------------------------------

Date:    Fri, 14 Jun 91 16:05:27 +0000
From:    dave@nucleus (Dave Coder)
Subject: Re: Help With Frodo & Yankee Doodle (PC)

[e-mail] (Alan Jones) writes:
>            FRODO & YANKEE DOODLE
>
> Has anyone got any information on these two viruses.
> They have just arrived on the campus ( 2000+ computers ),

Norton Antivirus 1.0.0 gets both Yankee Doodle (various forms) and
Frodo (4096). You can install as RAM-resident program to check
incoming files. It works.

Dave
[e-mail]

------------------------------

Date:    Fri, 14 Jun 91 13:12:04 -0700
From:    [e-mail] (Rob Slade)
Subject: Infected networks (PC)

[e-mail] (A. Padgett Peterson) writes:

> In this case I had such a self-check program (1400 bytes) that just
> checks its own length & checksum. If it passes, the program exits, if
> it fails, the client machine displays a warning message and is locked
> up. In this manner, the server application files are protected from
> infection (are never called by an infected client). Each client gets a
> new copy of the "goat" file so clean clients are not affected, and
> infected clients are identified.

I have been reviewing a product from Bangkok called Victor Charlie
that takes a similar approach.  An intriguing concept.

I hope to be able to release the review shortly.

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Sat, 15 Jun 91 01:09:56 +0000
From:    [e-mail] (Albert Lunde)
Subject: Re: Questions about "Disinfectant" (Mac).

[e-mail] writes:
> 1.  I believe since version 2.0, Disinfectant had the ability to install
>     a protection INIT.  The thing is only 5k... What does it DO?...
>     Does it just give a warning if something is being infected?
>     What does it look for?

It is small because it is written in assembly, with no configuration
options.  It tries to prevent virus infection from being successful,
and issue an informative message via the notification manager.  The
means used to block infection vary according to the virus.  Like
Disinfectant it is effective against a list of known viruses, and
tries to be specific enough to avoid false alarms.

It does not scan files on every inserted disk for say, nVIR.

> 2.  I remember hearing that using Disinfectant AND the old virus
>     protection
>     CDEV(?) "Vaccine (TM) 1.0.1" was a bad idea (Vaccine somehow
>     rendered the
>     Disinfectant INIT useless or something to that effect).
>       Is it also a good idea to remove the INITs "KillVirus" (Icon is a
>     needle with the word nVIR next to it). and "Kill WDEF - virus INIT"
>     (Icon is just a standard document icon)?  I know these are pretty old
>     too.  (at least I don't have "Ferret" and "Kill Scores" and those
>     other
>     related relics)

We are currently advocating that general users at Northwestern use
only the Disinfectant INIT and not Vaccine or Gatekeeper Aid, and that
they get periodic updates.

The risk from unknown viruses seems balanced by the reduced grief to
general users.  The rate of virus spread is slow enough that this is
workable.

Vaccine presents unclear messages, bombs on application startup under
many real infections and is bypassed by other newer viruses and has a
few minor bugs unrelated to viruses.

Gatekeeper Aid has occasionally removed the CODE resources from my
running applications.  Like the other Gatekeeper tools, I think it is
useful for advanced users, but too paranoid and subject to false
alarms for average Mac users.  There is a tradeoff between detecting
suspicious activity and being quiet and specific. (See discussion in
the Disinfectant online help.)

I would not recommend "KillVirus" - it seems to be one of many early
nVIR tools, that are not as generally effective as the Disinfectant
INIT. I know nothing about "Kill WDEF - virus INIT", but it is not
needed if you use the Disinfectant INIT.

> 2a. Almost forgot... What about "SAM (TM) Intercept" INIT... I know it's
>     newer but do "SAM" and "Disinfectant" interfere with each other?

I think that these can co-exist, but I don't remember which takes priority.

> My current version of Disinfectant is 2.4... Is this the most current
> one?  I've had it for about 6 months now.

Yes 2.4 is current - see John's prior post about it and system 7.

Albert Lunde - Northwestern University  This post represents neither NU
[e-mail]                                    or John Norstad

------------------------------

Date:    Fri, 14 Jun 91 15:09:32 -0500
From:    Paul Coen <[e-mail]>
Subject: Getting register contents, etc. "on the fly." (PC)

If you want to find out what's in memory at a particular location, and
you're lucky enough to be using a Zenith computer (at least, on every
Zenith I've seen except the Eazy-PC -- it had a non-Zenith BIOS), you
can press ctrl-alt-return (enter, whatever), at pretty much any time,
and be thrown into what Zenith calls a "monitor program" -- the same
one you get when you press ctrl-alt-ins.  Only in this state, it shows
you the memory contents at the current location.  You can change,
examine, etc. from this point.  If you type "g" and press return,
you'll go back to executing the program where you left off, assuming
you didn't mess with anything important.  It's essentially a built-in
debugger.

Apologies to anyone who doesn't have a Zenith, but look on the bright
side, this feature can cause incompatability problems on rare
occasions.

------------------------------

Date:    15 Jun 91 09:05:24 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Problems removing Azusa (PC)

[e-mail] (A. Padgett Peterson) writes:
>From:    [e-mail] (Derek William Ebdon)
>One thing that Mr. Doss forgot to mention is that although Central
>Point Anti-Virus v1.0 can easily romove the Asuza virus from a floppy,
>it cannot remove the virus from a hard drive.  The only way to
>disinfect a hard drive is to redo the low level format because the
>virus infects the boot sector and the dos partition.  A high level
>format will not remove the virus, nor will simply removing the dos
>partition with the fdisk program.

Well, this is of course not correct - a format is never necessary to
get rid of a virus - boot sector or otherwise.  However, Azusa is
rather problematic, as it does not store the original PBR anywhere -
it simply replaces it.  (It is easy to remove Azusa from diskettes)

Suggested solutions:  1) Use NU to zero out the PBR, then use
             NDD to rebuild it.

              2) Use a disinfection program which can replace
             the PBR with a "standard" PBR - such programs
             exist.

- -frisk

------------------------------

Date:    15 Jun 91 09:12:01 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: Is there a 1024 virus? (PC)

Arthur Buslik writes:

>As Rob Slade suggests, one possibility is a virus.  However, a much
>more likely possibility is that the computers have extended bios
>extended data areas.
:
>Moreover, INT 15H, AH=C1H will return the segment address
>of the base of the extended bios area.

Well, not always - I have a HP/Vectra, where the BIOS reserves a 4K
area just below the 640K mark.  However, INT 15H, AH=C1H is not
implemented in the BIOS (I know - I traced through it), and INT 15H,
AH=C0H will return the information that no Extended BIOS area is used.

- -frisk

------------------------------

Date:    Sat, 15 Jun 91 09:46:41 -0400
From:    Jeff <[e-mail]>
Subject: Fprot v1.16 (PC)

Is Fprot v1.16 avaiable yet? If so where can I ftp it? Thanks.

------------------------------

Date:    Sun, 16 Jun 91 01:19:14 -0400
From:    Daniel Pan <[e-mail]>
Subject: Why I didn't find the virus.exe (PC)

A friend of my got viruses.  I use scan v77 to check it found the
partition table was infected by sotned and the file
C:\DOS\KILL\VIRUS.EXE was infected by jerusalem.  I also use Virx 1.14
to check the C drive, the only hard drive she has, and find stoned-b.
But I could not find the file VIRUS.EXE exist. The kill subdir only
has four files and neither is VIRUS.EXE. Does any one know what
happened ? could it be a hidded file or Scan gave the fault alarm ?
But the Clean did doing very well when cleaned those viruses.  I
cleaned the hard disk before I thinking about this question!

------------------------------

Date:    Sat, 15 Jun 91 23:34:48 -0700
From:    p4tustin![e-mail] (ofa123)
Subject: Re: Hoffman Summary & FPROT (PC)

I think it's just too bad that Hoffman's summary keeps ignoring the
latest versions of F-PROT. The SCANV shown is always the latest issue.
Frisk, are you looking for distribution sites in the US? I may have a
couple of systems that would be interested in becoming official
distribution sites for F-PROT. Please let me know.

- --- Opus-CBCS 1.14
 * Origin: Universal Electronics, Inc. [714 939-1041] (1:103/208.0)
- --
Ray Mann
Internet: [e-mail]
Compuserve: >internet:[e-mail]

------------------------------

Date:    Sun, 16 Jun 91 10:56:44 -0500
From:    James Ford <[e-mail]>
Subject: New address and hostname for MIBSRV (PC)

The mibsrv antiviral site (MIBSRV.MIB.ENG.UA.EDU) is moving to the new
location RISC.UA.EDU (130.160.4.7).  The directory structure will
remain the same.  At this time, all ibm-antivirus have been moved
over.  The solutions directory (pub/games/solutions) will me moved
Monday.

MIBSRV (130.160.20.80) will stay up until June 26.  After that time,
it will be gone / kaput / lost_in_time / lost_in_space.

Please make any necessary changes in your script / information files
regarding this.  If you have any problems, please let me know.
                 /\/\/\/\/\/\/\/\/\/\/\/\  /\/\/\/\/\/\/\/\/\/
- ----------
Life is one long process of getting tired.
- ----------
James Ford -  [e-mail], [e-mail]
              The University of Alabama (in Tuscaloosa, Alabama)

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 103]
******************************************
VIRUS-L Digest   Tuesday, 18 Jun 1991    Volume 4 : Issue 104

Today's Topics:

Re: Checksumming
Info on Disk Killer? (PC)
virus detection by scanners ? (PC)
Master Boot Record (PC)
Re: Is there a 1024 virus? (PC)
Re: Virus scanners (PC)
"Beijing Virus - Urban Legend?"
Re: Scanning infected files (PC)
Re: Virus-writers
Result of preliminary research for Hard Disk Write-Protect (PC)
Re: Is there a 1024 virus? (PC)
Re: DOS 5 Fdisk, etc (PC)
Possible PC Virus (PC)
Interesting interaction (PC)
joshi & vsum & f-prot & ll format (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Mon, 17 Jun 91 13:07:00 +0300
From:    Y. Radai <[e-mail]>
Subject: Re: Checksumming

  Mike Lawrie writes:
>                         ... sooner or later this scenario [infecting
>files by performing SCAN while a virus like Plastique is in RAM] will
>re-occur, as you will get hit with a similar type of virus that McAfee
>has not yet catered for, even if you have their very latest version.

Right; I specifically stated that that could happen, and I mentioned
that in order to prevent such occurrences, you could add a good gene-
ric monitoring program.  You didn't reply to that suggestion.  But
actually, there is a surer solution which I mentioned only later on
in my posting, but which I should have mentioned here also: If you
want to be certain that such occurrences cannot occur, never run a
program like SCAN or a checksummer except when you are certain that
RAM is clean, i.e. only immediately after booting from a clean disk-
ette.  (Authors of such programs should mention this; if they don't,
and that apparently includes McAfee, you have a legitimate gripe
against them.)

>                                         A checksummer gives you no
>security whatsoever, because it does not prevent a viral infection.

True, a checksummer does not prevent infection, but at least it can
*detect* infections, and that's a lot better than no security at all!!
Knowing that certain files are infected, you can restore your files
from backups or use a disinfector, something which you wouldn't do if
the infections were not detected.
  Moreover, if the checksummer is properly designed and implemented,
(1) it can detect *all* infections, and (2) it cannot be neutralized
or circumvented by hostile software.  These are advantages that are
almost impossible to find in any other anti-viral software.

  In my opinion, the best software solution is a *combination of
several* programs: a good checksummer (like V-Analyst), a good generic
monitor (like Secure), a known-virus scanner (too many to mention
names), a program which prevents infections through floppy boots (to
be mentioned soon), and more.  I use all of them; the resident
programs don't take up much RAM, and they coexist peacefully (well,
most of them ...).

>Just that our experience that I wished to share was that with a
>checksummer in place and use of SCAN, you can end up with every last
>EXE/COM file on you hard disk looking very sick indeed.

Quite true ... *if* you don't take the proper precautions.

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]
                                     [e-mail]

------------------------------

Date:    Mon, 17 Jun 91 08:25:00 -0800
From:    [e-mail] (Rose Briggs)
Subject: Info on Disk Killer? (PC)

I have had quite a few requests about "Disk Killer" as to the
symptoms, prevention and what damage it does, etc.  Does anyone have a
comprehensive overview of this virus?

Thanks
Rose Briggs/NASA HQ
[e-mail]
[phone]

------------------------------

Date:    07 Jun 91 14:33:23 +0000
From:    [e-mail] (Hermann Stamm)
Subject: virus detection by scanners ? (PC)

Hello everybody on this list !

I have a few questions concerning detection of virii in general and
1701 in special.

First of all, I hope that only good guys are on this list, because the
remarks made here would otherwise result in hundreds of newly virii.

Let me begin with the story:
Two years ago I bought a diskette containing chess-programs from a
PD-distributor. The chess-programs were ok, but the list.com on that
disk was infected with the 1701 virus.  I recognized this, as the
first character falls down my screen with noise. After booting from a
clean diskette I found the modified files, found a search-string to
identify 1701, and wrote a program for detection and removing the
1701-virus. This was my first and up to now last personal contact with
any virus (I hope there is none I didn't recognize).

Now, as I tested scanv77 against the original diskette from the
distributor, I asked myself, how one can fool the detection mechanism
of virus-scanners. The keypoint in the case of 1701 is, that only 33
bytes of the decoding-mechanism are in executable form present, the
rest ist coded dependent on the length of the file 1701 is appended
to.  Now any scanner has to look for these 33 bytes only, I think.
But, after a few modifications of these 33 bytes (permuting the order
of execution, changing the names of used registers, or totally
rewriting an equivalent code), the modified 1701 is the same besides
its decoding-part, but isn't detected by scanv77.  I have tested this
versions on a portable without (!) any harddisk, and, after
activation, the new virii propagate in the changed form.

Now my questions:

  - what other scanner should I try for these versions ?

  - is it true, that any scanner must try to look at the
    semantics of such decoders, and not at the shape ?
    (undecidable problem ?)

  - which systems are good by looking at the length of
    files and reporting differences ?

  - Is the following behaviour possible for a virus:

    After getting resident, it forces to do a warm-start
    with ctrl-alt-del, and then it copies itself to all
    .com-files encountered during rebooting
    (like command.com, ...).

    I think, that this is the way most of my .com-files
    were infected.

Below are the decoding parts, first the one I received by the
distributor, then two modifications, which aren't detected by scanv77.

- ------------------------------------------------------------

Original decoding of 1701
- -u0109 012a
1DBD:0109 FA            CLI
1DBD:010A 8BEC          MOV    BP,SP
1DBD:010C E80000        CALL    010F
1DBD:010F 5B            POP    BX
1DBD:0110 81EB3101      SUB    BX,0131
1DBD:0114 2E            CS:
1DBD:0115 F6872A0101    TEST    BYTE PTR [BX+012A],01
1DBD:011A 740F          JZ    012B
1DBD:011C 8DB74D01      LEA    SI,[BX+014D]
1DBD:0120 BC8206        MOV    SP,0682
1DBD:0123 3134          XOR    [SI],SI
1DBD:0125 3124          XOR    [SI],SP
1DBD:0127 46            INC    SI
1DBD:0128 4C            DEC    SP
1DBD:0129 75F8          JNZ    0123
- -q

Modified, only SP replaced by DX, switch of first 2 stats
- -u 0109 012a
1DC6:0109 8BEC          MOV     BP,SP
1DC6:010B FA            CLI
1DC6:010C E80000        CALL    010F
1DC6:010F 5B            POP     BX
1DC6:0110 81EB3101      SUB     BX,0131
1DC6:0114 2E            CS:
1DC6:0115 F6872A0101    TEST    BYTE PTR [BX+012A],01
1DC6:011A 740F          JZ      012B
1DC6:011C 8DB74D01      LEA     SI,[BX+014D]
1DC6:0120 BA8206        MOV     DX,0682
1DC6:0123 3134          XOR     [SI],SI
1DC6:0125 3114          XOR     [SI],DX
1DC6:0127 46            INC     SI
1DC6:0128 4A            DEC     DX
1DC6:0129 75F8          JNZ     0123
- -q

Modified, only SP replaced by AX, switch of first 2 stats,
permutation of statements (i.e. 0110 MOV AX,0682)
- -u 0109 012a
1DBD:0109 8BEC          MOV     BP,SP
1DBD:010B FA            CLI
1DBD:010C E80000        CALL    010F
1DBD:010F 5B            POP     BX
1DBD:0110 B88206        MOV     AX,0682
1DBD:0113 81EB3101      SUB     BX,0131
1DBD:0117 8DB74D01      LEA     SI,[BX+014D]
1DBD:011B 2E            CS:
1DBD:011C F6872A0101    TEST    BYTE PTR [BX+012A],01
1DBD:0121 7408          JZ      012B
1DBD:0123 3134          XOR     [SI],SI
1DBD:0125 3104          XOR     [SI],AX
1DBD:0127 46            INC     SI
1DBD:0128 48            DEC     AX
1DBD:0129 75F8          JNZ     0123
- -q

Thanks in advance for any hints and answers to my questions,

   Hermann.

[e-mail]


------------------------------

Date:    Mon, 17 Jun 91 11:52:37 -0400
From:    [e-mail] (A. Padgett Peterson)
Subject: Master Boot Record (PC)

>From:    [e-mail] (Fridrik Skulason)

>[e-mail] (A. Padgett Peterson) writes:
>>From:    [e-mail] (Derek William Ebdon)
>>One thing that Mr. Doss forgot to mention is that although Central
>>Point Anti-Virus v1.0 can easily romove the Asuza virus from a floppy,
>>it cannot remove the virus from a hard drive.  The only way to
>>disinfect a hard drive is to redo the low level format because the
>>virus infects the boot sector and the dos partition.  A high level
>>format will not remove the virus, nor will simply removing the dos
>>partition with the fdisk program.

Aw come on fella, give a fella a break: I didn't say that, Mr. Ebdon
did.

The Master Boot Record, aka the Partition Table Record, aka physical
sector one on the hard disk contains two distinct elements:

1) The partition table located at offset 1BEh-1FCh (what is read by NU in
   partition table format).
2) The executable code beginning at offset 0 that uses the table to find
   the O/S boot record (also contains ASCII error messages).

Since the AZUSA replaces part 2 with its own code, all that is
necessary for recovery is to mate a good part 2 with the existing part
1 (not really difficult but more complicated than just copying a
sector) and replace the infected sector.

Things get a bit more complicated if special code is in use e.g. the
selection code used with COHERANT or other MBR replacement code
(DISKSECURE does this which is why the original MBR is backed up three
times during the installation process including once on floppy).

However, I have NEVER had to do a low-level format on a disk because
of a virus, & have been able to restore infections from both AZUSA and
MUSICBUG without any great difficulty, it is just a matter of
following the correct procedure, nor have I ever advised anyone to do
so.

            Hotly (having rolling blackouts of my a/c),

                            Padgett

------------------------------

Date:    Mon, 17 Jun 91 13:03:00 -0400
From:    Al Woodhull <[e-mail]>
Subject: Re: Is there a 1024 virus? (PC)

>  Can anyone suggest an explanation of our observation on several
>  computers (various IBM pc types) of a result from chkdsk of 654336
>  bytes of total memory?

On one of the computers I use I have determined that the ROM BIOS
reserves 1 K at the top of RAM memory. I first discovered this while
teaching my assembly language students about memory allocation, in
preparation for an assignment to implement some of the ideas in
Padgett's Six Bytes paper, and I was a little startled to think that a
virus might have been present in my own system for an unknown period
of time while I was playing local expert.

I verified that it was the ROM by booting from floppies with different
DOS versions that worked OK on other systems.

I don't know the purpose of this memory reservation, when I look at it
with DEBUG it seems to have been initialized to all zeros, but a few
bytes scattered throughout have other values.

The ROM in this machine is identified as DTK Corp.  COMPUTER XT,
DTK/ERSO/BIOS 2.29 (C) 1986.

 -- Al    [e-mail]

------------------------------

Date:    Mon, 17 Jun 91 13:05:00 -0400
From:    Al Woodhull <[e-mail]>
Subject: Re: Virus scanners (PC)

> The only "test target" that can be used is the entirety of a virus,
> and at that point you no longer have a "simulator", you have the real
> thing.  -- Fritz Schneider

I have only had serious problems with two viruses, Yankee Doodle and
Jerusalem.  For each of these I took a file that was infected from my
"zoo" disk, and appended it to a small program that prints a message
and exits. I saved the hybrid files as executables. (I did all of this
with DEBUG). The new files contain all of the infected code and so are
good test targets, but since there is no way to execute the infected
code it is essentially just a block of data. There is no need to worry
about someone else using my computer wondering "I wonder what that
program does?"

 -- Al    [e-mail]

------------------------------

Date:    Mon, 17 Jun 91 20:38:41 +0000
From:    [e-mail] (Brian D. Howard)
Subject: "Beijing Virus - Urban Legend?"

Over the weekend on CNN was a reference to a 'computer virus'
triggered by the anniversary of the tianamin massacre.  Other than the
brief reference here to allegations of such, was there a *documented*
sighting of such a beastie?  (Not that I usually put much credence in
CNN reporting on technical things, but I wondered if the story was
based on anything *other* than an FOAF anecdote from this newsgroup.)

- --
"Hire the young while they still know everything."

------------------------------

Date:    17 Jun 91 21:17:51 +0000
From:    [e-mail] (Johnathan Vail)
Subject: Re: Scanning infected files (PC)

[e-mail] (Finnegan Southey) writes:

     In regards to the problem of anti-viral programs infecting files
   they scan when a memory-resident virus is present: Wouldn't it be
   possible to read disks sector by sector instead of opening files
   through DOS calls?  This reading would be much the same as a disk
   editor program.  The scanner could consult directory listings to find
   program boundaries and then check approp- riate areas without opening
   the files as a file?  As I'm not an MS-DOS expert I'm not sure if this
   makes sense, but I thought I'd ask.

Good question, but: wouldn't it be possible for the stealthy virus to
trap the sector I/O and "fix" it to also hide its tracks?

Hardware level I/O is about the only way to go for this and then you
still have to be careful on a 386 where the MMU can trap hardware
accesses.

jv


"Always Mount a Scratch Monkey"
 _____
|     | Johnathan Vail | [e-mail]
|Tegra| [phone] | N1DXG@448.625-(WorldNet)
 -----  [e-mail] {...sun!sunne ..uunet}!tegra!vail

------------------------------

Date:    17 Jun 91 21:13:08 +0000
From:    [e-mail] (Johnathan Vail)
Subject: Re: Virus-writers

[e-mail] (Fridrik Skulason) writes:

   [e-mail] (A. Padgett Peterson) writes:
   >According to this (PC) week's Spencer Katt column, certain anti-viral
   >software houses are boosting their counts by soliciting viruses for
   >pay and programmers are taking them up for "big bucks".

   If that is true, I and and the Virus Bulletim would very much like to
   know which companies are involved - I would do my best to drive them
   out of business.....

And well you should.  I would find this hard to believe.  I would tend
believe Spencer Katt as much as I would Dave Berry or Andy Rooney.

I do believe that the anti-virus companies are hyping up the fear of
viruses in order to sell more product.  I have been working with
personal computers since 78 and with the exceptions of the viruses
that I wrote myself (the first one was in 1980) and a Mac virus that
went around here at work last year I have never seen or heard a first
hand account of a virus.

Of course I don't do much with shareware or BBS downloading which is
where I imagine most of the problems are.

jv <<-- Of course I will probably be bummin' when I do get hit...

"It's not a cormorant it's not a shag.
  Its just something in a plastic bag" -- RH
 _____
|     | Johnathan Vail | [e-mail]
|Tegra| [phone] | N1DXG@448.625-(WorldNet)
 -----  [e-mail] {...sun!sunne ..uunet}!tegra!vail

------------------------------

Date:    Tue, 18 Jun 91 00:53:45 +0000
From:    [e-mail] (steven l. odegard)
Subject: Result of preliminary research for Hard Disk Write-Protect (PC)

I want to leave a XT with 30Mb hard disk available for public access, and still
preserve the data on it.  I proposed a five-position keyed switch with the
following positions:

  R.  All of 0 below applies, and the reset line to the XT is activated.
       The key springs to position 0.

  0.  All of I below applies, and the keyboard lock on the machine is
       enabled.

  I.  Hard disk is not powered up on startup, however, if the key is moved
       from position II, the HD is not powed down.  In that case, all write
       and read access to the HD is blocked.

  II. All write access to the hard drive is blocked.

  III.  All read and write access to the drive is permitted.

The key is removable from all of the positions except R.

My proposal received one reply which I foolishly misplaced, of how the
write line to the disk can be shorted to high by a audio jack.  However,
for some controllers the machine will not boot up in that case.

------------------------------

Date:    Tue, 18 Jun 91 13:16:00 +1200
From:    "Mark Aitchison, U of Canty; Physics" <[e-mail]>
Subject: Re: Is there a 1024 virus? (PC)

[e-mail] (Fridrik Skulason) writes:
> Arthur Buslik writes:
>>As Rob Slade suggests, one possibility is a virus.  However, a much
>>more likely possibility is that the computers have extended bios
>>extended data areas.
> :
>>Moreover, INT 15H, AH=C1H will return the segment address
>>of the base of the extended bios area.
>
> Well, not always - I have a HP/Vectra, where the BIOS reserves a 4K
> area just below the 640K mark.  However, INT 15H, AH=C1H is not
> implemented in the BIOS (I know - I traced through it), and INT 15H,
> AH=C0H will return the information that no Extended BIOS area is used.
>  - -frisk

I have heard that often the port address of LPT4 (location 40E hex)
contains the segment address when a kilobyte or so is "stolen" for
(e.g.) a mouse driver. So that's another thing to look for. But it,
and the int 15 test, shouldn't be taken as definative answers that a
virus isn't there. I suspect the answer is to:

 (a) go through each important interrupt (13, 21, 2F, etc), tracing to see if
     any use that area, and
 (b) look through the code to see if there are interrupt calls, far calls to
     BIOS, disk port accesses, signs of self-modifying code, etc.

Alternatively, you could have some "known" valid users of the area in
a database and check that it is one of them there (and nothing else).
Wouldn't it be nice if someone compiled a list of software and BIOSes
that used the area? (any volunteers?)

Mark Aitchison, Physics, University of Canterbury, New Zealand.

------------------------------

Date:    Tue, 18 Jun 91 13:27:00 +1200
From:    "Mark Aitchison, U of Canty; Physics" <[e-mail]>
Subject: Re: DOS 5 Fdisk, etc (PC)

[e-mail] writes:
> Readers might want to play with an undocumented /MBR switch in DOS 5
> FDISK.  It appears to force FDISK to overwrite the code in a PC/PS2
> master boot record, without touching the partition table, and in
> limited testing on a half dozen machines it succeeded in cleaning up
> machines infected with the Stoned, the Stoned 2, and the Joshi
> viruses.  This was with the DOS 5 shipped by IBM, not Microsoft's DOS
> 5; can somebody please test MS-DOS 5?

On a related subject:
You may use the DRDOS 5 sys command to rewrite the boot sector (not
the MBR, I think), but watch out when you have a diskette infected in
such a way that the Bios Parameter Block (that says the disk size,
etc) has been junked (e.g. by stoned).  The SYS command rewrites a
good boot sector around it (fair enough), but acts on the size
information in the BPB, and you end up with a disk that needs to be
fixed with a disk editor. Remember that DOS normally ignores a lot of
the BPB and goes by the ID byte at the start of the FAT; this is
because early (version 1) DOS might write anything there. DRDOS reacts
sensibly if it contains junk *except* when it comes to the SYS
command, so beware.

Mark Aitchison, Physics, University of Canterbury, New Zealand.

------------------------------

Date:    Mon, 17 Jun 91 20:51:07 -0700
From:    [e-mail] (Rob Slade)
Subject: Possible PC Virus (PC)

[e-mail] (robert c. morales) writes:

> replicated themselves with such names as EDLIN._OM and AUTOEXEC._AT,
> all of which were 77 bytes in size with the same dates and times. This
> necessitated reformatting the hard drive. Also, the Dosshell was

Ouch.

I don't want to take any guesses as to your approximately 15K file, but I
would venture that someone has been wandering around your office with a
copy of Norton Antivirus, right?  The 77 byte files are the "file
signatures" that it uses to detect changes in infected programs.


=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Mon, 17 Jun 91 21:07:27 -0700
From:    [e-mail] (Rob Slade)
Subject: Interesting interaction (PC)

Noted an interesting interaction between two antivirals the other day,
and finally tracked it down.  If VIRx 1.4 is run before SCAN 77, SCAN
will "detect" the presence of the 3445 and Doom 2 viri in memory and
refuse to run.


=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Tue, 18 Jun 91 11:41:48 +0000
From:    [e-mail] (Terry N Reeves)
Subject: joshi & vsum & f-prot & ll format (PC)

    Vsum still says no utility will remove joshi and that low
level format is required f-prot says "Cured" whne I use it gainst
Joshi, but it still says infected after that, and the hard disk is no
longer bootable. v 1.15a.  those who know say ll-format NEVER needed.
I do not know how to manually rebuild partition table so I have done
three of these so far.

    Is their a utility Ms Hoffman? perhaps yuou just don't want to
admit it because McAffe's can't? (i have not tried McAffee but I
assume she'd say if his did.)

    f-prot must be intended to work - "cured" - so can the author
speak to this?

Thanks for any advice from any source

- --
 _____________________________________________________________________________
|                   That's my story, and I'm sticking to it!                  |
|_____________________________________________________________________________|
| Public Sites micro software support |   [e-mail]   |

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 104]
******************************************
VIRUS-L Digest   Tuesday, 18 Jun 1991    Volume 4 : Issue 105

Today's Topics:

Review of Victor Charlie 4.01 (PC)
Review of IBM VIRSCAN version 2.00.01 (PC)
Review of VirAway (PC)
Antivirus contact list (mostly PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Mon, 17 Jun 91 21:11:09 -0700
From:    [e-mail] (Rob Slade)
Subject: Review of Victor Charlie 4.01 (PC)

[Ed. My apologies for the length of this digest.  The reviews below,
and the vendor list, are available on cert.sei.cmu.edu for anonymous
FTP in the pub/virus-l/docs/reviews directory.  Thanks once again to
Rob Slade for all of this work which he is making available to all of
us!]

                               Comparison Review

Company and product:

Delta Base Enterprises
9800A - 140th St.
Surrey, B. C.
V3T 4M5
604-582-15922
Fax: [phone]
CIS# 72137,603
Bangkok Security Associates
BBS: 662-255-5981
Victor Charlie 4.0

Summary:

Change detection with self generating "bait" files and viral signature
capture

Cost   $99 Cdn

Rating (1-4, 1 = poor, 4 = very good)
      "Friendliness"
            Installation      2
            Ease of use       3
            Help systems      4
      Compatibility           2
      Company
            Stability         3
            Support           3
      Documentation           3
      Hardware required       4
      Performance             2
      Availability            2
      Local Support           2

General Description:

Victor Charlie is a series of batch and data files that generate a
number of programs for trapping of viral infections.  There is also
provision for the capture of viral signatures.  Utilities are included
for viewing of boot sectors and recovery of hard disk system areas.
Requires DEBUG.COM for some operations.

Version 5.0 has, as of this writing, been released, but has not yet been
received for review.  Due to the novelty of the program, and its
relative anonymity in North America and Europe, I am releasing this
review now, with some notes about version 5.0, rather than wait for the
next version.

                  Comparison of features and specifications



User Friendliness

Installation

The installation procedure outlined in the manual starts "earlier" in
the process than any other reviewed so far.  Not only does it recommend
booting from a floppy, but it suggests that you SYS and replace the
COMMAND.COM file on the hard disk before doing anything else.  An
initial "Quick Start" section of the manual relies on an intermediate
knowledge of MS-DOS by the user, but this is stated at the beginning.
(Unfortunately, it does not immediately point novice users to the later,
and more detailed, VINSTALLATION chapter, nor does it point out the
possible dangers of replacing the operating system on the hard disk.
Also, although there is some discussion is the alter chapter about the
DOS disk, some discussion of the importance of write protection of the
original disks might avoid possibilities for infection at this point.)

Installation of VC is not foolproof by any means.  Almost all error
messages are hidden from the user, and a lack of file space or an
incorrect assumption regarding drive specifications will cause the
installation to fail to complete.  This, however, is not communicated to
the user, and may not be obvious.  To the novice this can be dangerous,
in that the user may consider that the system is protected when, in
fact, it is not.  Experienced users will be able to custom tailor the
installation to their own needs, since everything is done through batch
files.

Although the documentation does indicate that the package can be run on
floppy only systems, installations onto floppies is problematic.  If the
command VINSTALL A: is given, the system will determine that A: is not a
hard drive, and install only a portion of the full set of files.  If,
however, the command VINSTALL A:\VC is given, the program will not
determine that A: is a floppy.  When installing to a floppy drive, the
boot sector and other system areas are "protected" (VC will detect an
infection by a BSI), but not reparable (the back file of the boot sector
is not generated.)  A floppy installation program, FINSTALL.BAT, is
provided, but it does not seem to work properly unless called from
VINSTALL.  Even then, on every attempt to install the program terminated
with an error message about an improper drive or path specification.

Although not mentioned in the manual until page 64, DEBUG.COM is
required by a number of VC's programs.  It should be on the computer,
and in a directory in the active path.

Options in regard to installation are legion, but should be performed
only by experienced users, as they are not necessarily well explained
for the novice.

Path and directory settings are vitally important, and it is quite
possible to generate additional copies of the program which no longer
will trap changes to programs.

Ease of use

The ability to use the programs effectively is very much dependent upon
the installation chosen.  With proper installation, occasional virus
checks can be as simple as a single keystroke (Alt-V).

The program can, however, give conflicting messages.  When the Stoned
virus was active, it correctly detected that something had happened to
the boot sequence.  On a floppy system it was not able to recover the
boot sector, but finished the sequence with a message that "Right now,
you have NO active virus on this computer."

Help systems

There is help of various sorts provided for, but in testing the program
very often "lost" its help file, even when installed as directed.

When a virus is detected, the messages that appear give a useful
explanation of what has happened and why.  The steps to take, and
optional explanations of what has happened are realistic, and should be
clear even to a novice.

Compatibility

Although no part of the package is "resident", it warns against having
TSR's active during installation.

Company Stability

The program is produced by Bangkok Security Associates (programmer John
DeHaven, technical writer Alan Dawson, marketing director Simon Royle
and financial director Ramesh Indhewat).  BSA is a Thai company
registered in the British Virgin Islands from Hong Kong.

Company Support

In Australia, where the product has had its major success to date, the
product is supported by Combat Software.  Otherwise company support is
provided by the BBS listed above.

Documentation

The manual is entertainingly written, and contains a great deal of
information on viral programs in general.  Parts of the manual explain
computer operations to the novice in great detail.  There are, however,
other parts that give out brief, or even misleading, information.

(A note on this business of directions to novice users.  It may seem
like a "fractal" type of problem, in that no matter how much you
explain, there is still more to do.  For example, TBSCAN's documentation
suggests write protecting diskettes, and explains how to do it on a 3.5"
diskette, but not on a 5.25".  Victor Charlie does explain that you
should put a "... sticker ... over the notch at the right-hand side of
the disk when you look at it from the front."  However, failing to
mention that the notch is *square*, on the *side* of the disk cover and
that you cannot see the magnetic disk through it might allow some to
permanently read *and* write protect the disk by placing the sticker
over the drive head access slot.  Still, in many cases Victor Charlie
gives the best explanation to novice users yet reviewed.)

The tone of the documentation (both hardcopy and on disk) varies between
jingoism ("... ultimate security ... defeat any current or future
virus") and realism, while ultimately falling somewhat short in terms of
actual details.  In testing the system, I came to the conclusion that,
while suitable for any users as a warning system, technical personnel
will need more details as to the ultimate effectiveness, and how far to
trust the package.

Hardware Requirements

MS-DOS 2.0 or higher and a minimum 64K of RAM.

Performance

Unfortunately, even at this point, I am unable to state the performance
of the system with confidence.  It will find viral infections of
programs, and of boot sectors.  (In spite of the difficulties
encountered in installing the system to a floppy, it had no difficulty
in identifying "Stoned" infections on floppy.  Further testing revealed
that it was, somehow, detecting a change in the boot sector, rather than
memory.  Although the program checks memory and the system areas of the
disk, the "signatures" of the original system are not stored with
program file signatures.)

The actions of the package as a whole, regenerating itself from batch
and data files, are quite fascinating.  The program is a radical
departure from any other reviewed system, and should be a valuable extra
component for system security.

The change detection of the signature list may possibly be bypassed by a
sophisticated virus, as it depends upon file length and checksum, rather
than some of the more rigourous mathematical methods.  However, the
checksum is described by the company as "double-encrypted", and the
method of calculation and protection, while not user definable, is not
uniform throughout any release of the product.

The program, as it stands, is most useful against memory resident,
program file infecting viri.  Specific identification of sources of
infection is not strong.

Local Support

In Australia, provided by Combat Software.

Support Requirements

Installation of the program is possible for novice users with standard
computer configurations, but should likely be supported for any non-
standard systems.  Novice or intermediate users will require assistance
to identify the source of infection if a virus is detected.

                                 General Notes

This package is quite fascinating in its novel approach to virus
detection.  There are numerous shortcomings, but the approach could be a
valuable adjunct to current methods.  While the current implementation
has significant shortcomings, particularly in non-standard
configurations, the concept is a valuable one and, hopefully, future
development will make the package more valuable as a stand alone
product.

Version 5.0 is said to be a major rewrite and upgrade.  The virus
signature library, which contains only two signatures in version 4.01,
will identify all viral programs identified as "common" in the Hoffman
Summary listing (the date of the listing is not specified.)  The library
will also "accumulate" signatures as new viral programs are encountered.

Changes effective in version 5.0 will include a new interface and
installation process.  New utilities will be added, and protection
against "stealth" viri will be enhanced.  System requirements will
increase to 256K RAM and DOS 3.0 or higher, but the use of DEBUG.COM
will be dropped.  The documentation will include a 200 page book on
computer viral operations, with separate version specific technical
references.

copyright Robert M. Slade, 1991   PCVC.RVW   910617


=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Mon, 17 Jun 91 23:57:37 -0700
From:    [e-mail] (Rob Slade)
Subject: Review of IBM VIRSCAN version 2.00.01 (PC)

                               Comparison Review

Company and product:

IBM High Integrity Computing Lab
Thomas J. Watson Research Center
P. O. Box 218
Yorktown Heights, New York
USA      10598
Bill Arnold, author
David Chess [e-mail], [e-mail]
VIRSCAN 2.00.01 dated 910307


Summary:

Non-resident scanner with user extensible signature file.

Cost    $35 US for original license, $10 for upgrades, enterprise wide
license

Rating (1-4, 1 = poor, 4 = very good)
      "Friendliness"
            Installation      3
            Ease of use       3
            Help systems      3
      Compatibility           3
      Company
            Stability         3
            Support           2
      Documentation           3
      Hardware required       4
      Performance             3
      Availability            2
      Local Support           1

General Description:

IBM's VIRSCAN product appears to fall somewhat oddly between commercial
software and shareware.  Although IBM retains all rights to the program
(in a license agreement written as only IBM can), there is no printed
documentation, and the package is available on either single disks or
via the IBMLINK service.  The price is reasonable for an individual, but
almost absurdly low given the "enterprise wide" license.

VIRSCAN is a non-resident scanner with a non-encrypted and user
extensible signature file.  Command line switches can be used to obtain
a variety of information about the system.  The program makes no attempt
to disinfect or delete infections.

Recommended for any situation, but particularly for medium to large
companies and for intermediate to advanced users.
                  Comparison of features and specifications



User Friendliness

Installation

VIRSCAN, when supplied on disk, is shipped on "non-writable" diskettes.

IBM does not suggest installation on the hard drive at all.  The
suggested use of the program is to boot from a protected floppy, and run
the program from the floppy disk.  The documentation does give
directions on how to prepare a bootable floppy with the scanning program
on it.  These directions are very complete.  (Directions are even given
on how to write protect a 3 1/2" floppy disk, although they are not as
explicit for 5 1/4" disks.)

An explanation of "resident" viri is given, and directions for booting
from the original system floppy are given.  The directions do assume
that you have original IBM equipment and operating system disks, but
should be clear for most systems, even for novice users.

The documentation is written with the novice user in mind, and is, in
places, excellent.  Some "obvious" steps are missing in the directions,
but by and large they are very clear, and cover ground often missing in
the documentation of other products.

Ease of use

As the product has evolved, a number of command line switches have been
added.  The default settings, however, are very well chosen, and novice
users should not need to know the various options.  Advanced users will
be able to use them without problems.

One possible problem is that by default the scan proceeds to conclusion
even when the screen has filled with warning messages.  This should not
be a problem in normal operation, but may be of concern in scanning a
heavily infected system.  (The "-Z" switch will, however, cause the
program to pause at each signature found and this may be an acceptable
alternative.)

Help systems

Two levels of help are available from the command line, called by
switches.  (Somewhat counterintuitively, the "?" switch gives more
extensive and complicated assistance than does the "??" switch.)  As the
program is run from the command line only, "onscreen help" is not an
issue.

Compatibility

VIRSCAN will run under both DOS and OS/2, and will examine drives with
both DOS/FAT and HPFS file structures.

The structure of the signature file is outlined in the manual, and at
least one other scanning program obtained for evaluation (Thunderbyte
Scan from Frans Veldman) uses this same file format as a standard.  This
allows the use of additional signature information with the program, and
also allows users to add new signatures to update the package, or their
own signatures if a new virus is found.

Mention is made in the documentation of a switch to disable "high
memory" checking, which appears to indicate that the program will check
high memory by default.  The extent of this is not, however, clearly
specified in the documentation.  In a communication from David Chess, it
was explained that "high memory" is defined as the area between 640K and
1 meg.  No scanning is done above 1 meg.  (Note that when run from OS/2,
the program does *not* check system memory.  Memory is only checked when
the program is run from DOS or the DOS compatibility box.)

Company Stability

They'll probably be around for a while.

Company Support

Those on the Internet and Usenet who receive VIRUS-L/comp.virus will
have access to David Chess' postings and email address.  IBMLINK
subscribers will have access to upgrades and information.

Documentation

The documentation is available only in softcopy on the disk.  While
sections are excellent, the presentation and order of the manual
(VIRSCAN.DOC) would likely be daunting to the novice.

A major strength is the discussion of the weaknesses of the program, and
a warning against trusting it too far.

Hardware Requirements

The documentation does not state any minimum requirements for operation.

Performance

While VIRSCAN does not search for as many viri as FPROT or SCAN, it
catches all common viri.  Speed of operation is neither the slowest nor
the fastest tested, and is quite acceptable.

Note that VIRSCAN makes no attempt to disinfect or delete infected
files.

Local Support

Local support, even from IBM staff, is unfortunately undependable.
There are numerous instances of those staff who should, presumably, be
familiar with the product being unaware of its particulars and
availability, or even giving out false information.  (I was twice
contacted by IBM staff who *offered* to get me copies of the program for
evaluation, and then were unable to find it themselves.)  There have
been a number of cases of IBM local representatives giving versions
intended for internal use only to outside clients.

Support Requirements

The program should be suitable for any user.  Support staff will find
additional functions that novice users would not use.

If, however, an infection is detected, additional support will be
required.  It is likely that only advanced users would be able to take
effective action, and even then would likely require other antiviral
packages to correct the situation.

                                 General Notes

This product is an excellent value for any company.  It is easy to see
that IBM could lose control over the integrity of the product if it were
to be distributed as shareware or "freeware".  It is also reasonable
that IBM be allowed to make some return on the resources devoted to this
product.  That said, I still could wish for some attempt to make the
product more available to the general user community.

The lack of support available through IBM representatives is disturbing.
Against, while it is understandable that not all staff can be expert in
all products, the lack of support for a product of such universal
importance is to be regretted.

In comparison to other scanners, the lack of disinfection would tend to
make this product an adjunct rather than the only tool used.  It is
still, though, a high quality tool, and could easily be chosen as the
primary virus alert product.

copyright Robert M. Slade, 1991   PCIBMSCN.RVW   910617


=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Wed, 12 Jun 91 17:37:07 -0700
From:    [e-mail] (Rob Slade)
Subject: Review of VirAway (PC)

                               Comparison Review

Company and product:

T.C.P. Techmar Computer Products
97 - 77 Queens Blvd.
Rego Park, NY   11374
USA
800-922-0015
718-997-6800
718-997-6666
fax: [phone]
VirAway scanner version 1.46 dated 910128



Summary:

Non resident scanner

Cost    $49 US

Rating (1-4, 1 = poor, 4 = very good)
      "Friendliness"
            Installation      2
            Ease of use       3
            Help systems      1
      Compatibility           2
      Company
            Stability         3
            Support           2
      Documentation           1
      Hardware required       4
      Performance             2
      Availability            2
      Local Support           1

General Description:

VirAway is identical to the CURE program shipped with AntiVirus Plus
from Techmar.  The program is recommended only to "backstop" other
systems, and should not be depended upon as the only means of antivirus
protection in its current form.

                  Comparison of features and specifications



User Friendliness

Installation

VirAway, as shipped to me, comes completely unprotected.  This may not
be the usual form, as the disk documentation contains a READ.ME file
which states that no changes have been made to the documentation, while
I received no documentation with the package.

An installation program is provided, which will only install from drive
A: to the C: drive in a directory called \VIRAWAY.  However, as
installation consists solely of copying three files (and one "startup"
batch file to the root directory), it is not difficult for the
intermediate user to perform a "custom" installation.

Ease of use

Although VirAway came with no documentation, it responds to the same
command line switches as does CURE.  (Not terribly surprising: not only
are the files identical in size, but CURE, when run, identifies itself
as version 1.46 of VirAway.)  Again, if no switches are used, the
program will present a menu of options.

However, command line switches seem to be only able to "add" to the
default options.  (For example, one cannot turn off the display of final
statistics from the command line invocation.)

There is an annoying bug in the program when allowed to disinfect: it
appears to count both the infection detected, and the cleaning process,
as an infection.  The final statistics will indicate that 1 file virus
was found, and one cleaned, but will show the virus named as having
caused two infections.  (If two files are, in fact, infected, the
display shows only two infections.)

Help systems

None provided.

Compatibility

As stated in the review of AntiVirus Plus, VirAway will find most common
viri, but will not find the AIDS virus.

VirAway will find viri active in memory, and, in testing, rendered them
inactive.  However, sufficient traces remained in memory to set off
alarms from other virus scanners.

Company Stability

Techmar is the distributor of IRIS products (from Israel) in the United
States.

Company Support

The evaluation copy of AntiVirus Plus was shipped in good time, although
Techmar had not properly filled in the customs declaration.  The copy of
VirAway came unsolicited, which seems to indicate an active marketing
group if nothing else.

Documentation

Not supplied.

Hardware Requirements

MS-DOS 2.0 or higher, 256K memory.  The promotional material states that
a dual floppy system is necessary, which conflicts with the installation
batch file.

Performance

Detection of viral programs appears to be sufficient for most
situations.  Disinfection of memory appears effective, with the proviso
noted above about false alarms from other scanners.  (According to
memory mapping utilities, the memory is also still "reserved".)
Disinfection of boot sector viri appears to be effective.  Disinfection
of program files appears effective as to the virus removal, but may
leave programs damaged.

During testing, the memory was infected with the Jerusalem B virus
(which VirAway reports as "Black Friday #1").  When VirAway was run, the
virus was rendered inactive in memory, but it had already infected the
VirAway program file.  VirAway then disinfected itself, but increased in
size from 81835 to 81840 bytes on disk.  Subsequent runs with the
program against test sets of viri showed some odd behaviour and an
inability to identify all previously identified viri.  Also, subsequent
runs of VirAway in memory showed a lack of ability to remove infections
from memory.

Local Support

None provided.

Support Requirements

The program, while fairly simple to run, would not necessarily be
suitable for novice users.  Disinfection of viral infections is probably
best left to experienced staff (and possibly other programs.)

                                 General Notes

As it stands, the program cannot be highly recommended.  The number of
viri detected are low even by the standards of other (admittedly more
expensive) programs.  The disinfection ability is somewhat questionable,
and therefore undependable.

copyright Robert M. Slade, 1991   PCVIRAWY.RVW   910612


=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Tue, 11 Jun 91 23:35:59 -0700
From:    [e-mail] (Rob Slade)
Subject: Antivirus contact list (mostly PC)

As before ....

Sandy Jenish, Dave Reid (VP Marketing)
Advanced Gravis Computer Technology
7033 Antrim Avenue
Burnaby, B. C.
V5J 4M5
604-434-7274
Telecopier: [phone]
Advanced Security for PC and Mac

Brightwork Development Inc.
766 Shrewsbury Ave.
Jerral Center West
Tinton Falls, NJ  07724
USA
201-530-0440
800-552-9876 (US only)
fax: [phone]
Sitelock, Novell add-on operation restricting software $495
product not available

British Computer Virus Research Centre
12 Guildford Street, Brighton, East Sussex, BN1 3LS, England
Tel: [phone]
Joe Hirst
Virus Simulation Suite, Eliminator/Virus Monitor/Virus Clean
see also ICVI

Carmel Software Engineering
EPG International
Hans-Stiessberger-Strasse 3
D-8013  Haar by Muenchen
head office Israel?
Turbo Anti-Virus Set, scanner vaccine and change checker (including
boot)
product not available

Central Point Software
15220 N. W. Greenbrier Parkway #200
Beaverton, OR   97006
USA
503-690-8090
Central Point Anti-Virus

Certus International
13110 Shaker Square
Cleveland, Ohio   44120
USA
216-752-8181
216-752-8183 Technical Support
BBS 216-752-8134
fax [phone]
800-722-8737
Mike Mytnick, Cleveland
Michael Blumenthald (?), Anaheim
Peter Trippett, 4295370 on MCI mail
operation restricting software, particularly for LANs

ComNETco, Inc.
29 Olcott Square
Bernardsville, NJ   07924
USA
VirusSafe-Anti-Viral Software (cf EliaShim, also Enigma SafeWord (R)
Virus-Safe)
mail undeliverable

CSM Management and Consulting
3031 Main St.
Vancouver, B. C.
V5T 3G8
604-879-4162
Telecopier: 604-874-1668
Overlord
product not available

Cylink
110 S. Wolfe Road
Sunnyvale, CA  94086
USA
408-735-5800
telecopier: 408-738-8269
SecurePC - half card DES encryptor
product not available

PROGRAM CHAIRPERSON: DPMA Virus Conference, 1991
Richard G. Lefkon
NYU, DPMA Fin. Ind. Ch.
609 West 114th Street
New York, NY 10025
[phone]

Data Fellows Ltd
Finland
Ari Hypponen, [e-mail] [e-mail]
data security consulting

Delta Base Enterprises
9800A - 140th St.
Surrey, B. C.
V3T 4M5
604-582-1592
Fax: [phone]
CIS# 72137,603
Victor Charlie 4.0 - change detection

Digital Dispatch, Inc.
1580 Rice Creek Road
Minneapolis, MN   55432
mail undeliverable
55 Lakeland Shores
St. Paul Minn   55043
612-436-1000
800-221-8091
Antigen, Data Physician, Novirus-Anti-viral software
product not available

Director Technologies Inc.
906 University Place
Evanston, IL   60201
USA
Disk Defender-Half-Slot Virus Write-Interrupt Device
product not available

Dynamics Security Inc.
Cambridge, MA
USA
mail undeliverable

EliaShim Microcomputers
520 W. Hwy. 436, #1180-30
Altamonte Springs, Florida
USA
407-682-1587
VirusSafe - TSR scanner (cf ComNETco?)

Bob Bosen
Enigma Logic Inc.
2151 Salvio Street, #301
Concord, CA   94565   USA
Tel: [phone]
     [phone] (not from Canada)
FAX: [phone]
Internet: [e-mail]
Safeword - change detection software

Fink Enterprises
11 Glen Cameron Road, Unit 11
Thornhill, Ontario
L3T 4N3
416-764-5648
Telecopier: 416-764-5649
IRIS Antivirus (from Israel, cf Techmar)

FoundationWare
2135 Renrock Rd.
Cleveland, OH   44118
USA
Vaccine 1.2-Anti-viral software
mail undeliverable, now Certus

Gee Wiz Software Company
c/o Mrs. Janey Huie
10 Manton Avenue
East Brunswick, NJ   08816
USA
Dprotect-Anti-Trojan Software
product not available

Patricia M. Hoffman
1556 Halford Avenue, #127
Santa Clara, CA 95051
Voice: 1-408-246-3915
FAX  : [phone]
BBS  : 1-408-244-0813
Virus Summary Document
also distributed by:
Roger Aucoin
Vacci Virus
84 Hammond Street
Waltham, MA 02154
Voice: 1-617-893-8282
FAX  : [phone]

Denny Kirk
Hyper Technologies
211 - 3030 Lincoln
Coquitlam, B. C.
604-464-8680
Integrity
still in production, not yet available

IBM High Integrity Computing Lab
Thomas J. Watson Research Center
P. O. Box 218
Yorktown Heights, New York
USA      10598
Bill Arnold, author
David Chess [e-mail], [e-mail]
VIRSCAN

IMSI Software
San Rafael, CA
415-454-7101
BBS 415-454-2893
VirusCure Plus
product not available

International Computer Virus Institute
1257 Siskiyou Boulevard, Suite 179
Ashland, OR   97520
USA
503-488-3237
503-482-3284
BBS 503-488-2251
Eliminator anti-viral, virus simulators plus books and consulting
see also British Computer Virus Research Centre, Joe Hirst

Interpath Corporation
Cylene-4-Anti-Viral software, no longer produced
defunct, cf McAfee

IP Technologies
Virus Guard
address no longer valid

Lasertrieve, Inc.
395 Main Street
Metuchen, NJ   08840
USA
Viralarm-Anti-Viral Software
product not available

LeeMah DataCom Security Corp.
3948 Trust Way
Hayward, CA   94545
USA
415-786-0790
product not available

Leprechaun Software Pty Ltd
PO Box 134
Lutwyche  Queensland  4003
Australia
Lindsay Hough [phone]
Leprechaun International
2284 Pine Warbler Way
Marietta Georgia 30062 USA
404 971 8900
fax [phone]
Virus Buster
product not available

Look Software
Cliff Livingstone
Ottawa, Ontario
613-820-9450
Start - VIRUSCAN front end

Paul Mace Software
400 Williamson Way
Ashland, OR   97520
USA
tech support 503-488-0224
fax: [phone]
sold and supported through:
Fifth Generation Systems, Inc.
10049 N. Reiger Rd.
Baton Rouge, Louisiana
USA   70809
1-800-873-4384 sales and info
504-291-7283 tech support
504-291-7221 admin
telecopier: 504-292-4465
Mace Vaccine-Anti-viral software.

McAfee Associates
4423 Cheeney Street
Santa Clara, CA   95054
USA
408-988-3832
Viruscan-Scans disk and RAM for viri.
Morgan Schweers - [e-mail]
Aryeh Goretsky,Tech Sup.|voice(408)988-3832|INTERNET
McAfee Associates       |  fax[phone]|[e-mail]
4423 Cheeney Street     |  BBS(408)988-4004|[e-mail]
Santa Clara, CA  95054  | UUCP apple!netcom!nusjecs!ozonebbs!aryehg
[e-mail]
cynic!van-bc!apple.com!uuwest!aryehg
[e-mail]
cynic!van-bc!uunet!mimsy!ames!netcom.netcom.com!mcafee

Mike McCune
MMCCUNE@SCTNVE...<MM>.
FTP from mibsrv.mib.eng.ua.edu in pub/ibm-antivirus/innoc.zip
INNOC Boot Virus Immunizer, boot sector overlay renders non-booting

Microcom Software Division
3700-B Lyckan Parkway
Durham, NC   27717
USA
also Norwood, MA
919-490-1277
800-822-8224
Virex-PC, also Virex for Mac - scanner
Mary Hughes
Glenn Jordan - beta list Fidonet: 1:155/223
see also Software Concepts Design

Micronyx Inc
1901 N. Central Expressway
Richardson, TX
USA    75080
800-634-8786
fax: [phone]
Triumph security package (PC and LAN)
product not available

Computer Security Division
National Computer Systems Laboratory
National Institute of Standards and Technology (NIST)
225/A216
United States Department of Commerce
Gaithersburg, Maryland  20899
USA
310-975-3411
BBS 2400 bps 301-948-5717
BBS 9600 bps 301-948-5140
John P. Wack
Marianne Swanson (sysop)
[e-mail]
[e-mail]
wack@csmes
cynic!van-bc!csmes.ncsl.nist.gov!wack
[e-mail] (Dennis D. Steinauer)
steinauer.ncsl.nist.gov (CSME1.NCSL.NIST.GOV)
cynic!van-bc!csmes.ncsl.nist.gov!dds

Orion Microsystems
Quebec

Panda Systems
801 Wilson Road
Wimington, DE   19803
USA
Dr. Panda Utilities-Anti-Viral Software
product not available

Parsons Technology
375 Collins Road NE
Cedar Rapids, IA   52402
USA
319-395-9626
Virucide

A. Padgett Peterson, Computer Network Security
Orlando
[phone], 6384 work
[phone] FAX
[phone]
cynic!van-bc!uvs1.orl.mmc.com!tccslr.dnet!padgett
[e-mail] [host unknown]
note: To: "[e-mail]"[e-mail]
cynic!van-bc!uvs1.orl.mmc.com!tccslr.dnet![e-mail]
uvs1.orl.mms.com![e-mail]
Received: from TCCSLR.DECnet MAIL11D_V3 by uvs1.orl.mmc.com
DISKSECURE

PKWare, Inc.
7545 North Port Washington Road
Glendale, WI   53217-3442
USA
PKZIP, PKSFX-File compression utilities with encryption option

Prime Factors
1470 East 20th Avenue
Eugene, OR   97403
USA
VI-Raid-Anti-Viral Software
product not available

Publisher One
Baltimore, Maryland
Chris - [e-mail]
virus protection book (Jan '92?)

PYRAMID Development Corp
20 Hurlbut Street,
West Hartford, CT 06110
203-953-9832
Fax: [phone]
PC/DACS retail $249.00.
product not available

Quaid Software Ltd.
45 Charles Street East
Toronto, ON   M4Y 1S2
416-961-8243
Antidote-Anti-Viral Software
product not available

RG Software Systems Inc
6900 East Camelback Road
Suite 630
Scotsdale AZ 85251
[phone]
Diskwatcher 2.0, ViSpy
product not available

Fridrik Skulason
Box 7180
IS-127 Reykjavik
Iceland
[e-mail]
F-PROT-Virus detection/protection/disinfection and utilities

Ross Greenburg
Software Concepts Design
594 Third Avenue
New York, NY   10016
USA
Flushot-Anti-Viral Software.
see also Microcom

S&S International Ltd.
Berkley Court, Mill Street
Berkhamsted, Herts. HP4 2HB
England
Phone:   [phone]
Fax:     [phone]
BBS:     [phone] (used to be -- still valid??)
E-Mail:  Dr. Alan Solomon <[e-mail]>
Dr. Solomon's Anti-Virus Toolkit (SHERLOCK and HOLMES?)
Vendor:  perComp Verlag GmbH
Holzmuhlenstrasse 84
2000 Hamburg 70
Germany
Phone:   [phone]
Fax:     [phone]
E-Mail:  Gunter Musstopf <[e-mail]>
product not available

Luis Bernardo Chicaiza Sandoval
Phone: [phone]
Universidad de los Andes Bogota, Colombia
mail address: <[e-mail]>
Compucilina  US$70, adds self check module
review copies not available

SECTRA
Teknikringen 2
S-583 30 Linkoping
SWEDEN
Telephone: [phone]
FAX: [phone]
[e-mail]
TCell unix change checker

Sophco
P.O. Box 7430
Boulder, CO   80306
USA
Vaccinate-Anti-Viral Software
product not available

Sophos Limited
20 Hawthorne Way
Kidlington, Oxford,    OX5 1EZ
UK
Vaccine-Anti-Viral Software
product not available

Swarthmore Software Systems
526 Walnut Lane
Swarthmore, PA   19081
USA
Bombsquad, Check-4-Bomb-Anti-Trojan software

Stratford Software
#2047-4710 Kingsway
Burnaby, BC  V5H 4M2
[phone]
SUZY Information System, INtegrity antivirus information network

Symantec/Peter Norton
10201 Torre Avenue
Cupertino, CA   95014
USA
408-253-9600
800-343-4714
800-441-7234
408-252-3570
416-923-1033
Norton AntiVirus

Tacoma Software Systems
7526 John Dower Road W.
Tacoma, WA  98467
VIRSTOP 1.05

T.C.P. Techmar Computer Products
97 - 77 Queens Blvd.
Rego Park, NY   11374
USA
800-922-0015
718-997-6800
718-997-6666
fax: [phone]
    IRIS Antivirus (cf Fink), Antivirus Plus (purported "AI vaccine"),
         VirAway scanner

Tomauri Inc.
30 West Beaver Creek Road, Unit 13
Richmond Hill, Ontario
L4B 3K1
416-886-8122
Telecopier: 416-886-6452
PC Guard - password protection board, also for Mac
product not available

Trend Micro Devices Inc.
2421 W. 205th St., #D-100
Torrance, CA   90501
USA
213-782-8190
fax: [phone]
PC-cillin - program change detection hardware/software

University of Cincinnati
Dep't. of Computer Engineering
Mail Loc. 30 - 898 Rhodes Hall
Cincinnati, OH   45221-0030
USA
Cryptographic Checksum-Anti-Viral software

Vacci Virus
84 Hammond Street
Waltham, MA 02154
Voice: 1-617-893-8282
FAX  : [phone]
distributes Hoffman Virus Summary Document, other products unknown

Vancouver Institute for Research into User Security
3118 Baird Road
North Vancouver, B. C.
V7K 2G6
604-984-9983
virus research archives, seminars, vendor contact list, product reviews,
consulting

Frans Veldman
ESaSS B.V.
P.o. box 1380
6501 BJ  Nijmegen
The Netherlands
Tel:  31 - 80 - 787 771
Fax:  31 - 80 - 777 327
Data: 31 - 85 - 212 395
    (2:280/200 @fidonet)
c/o Jeroen W. Pluimers/Smulders
P.O. Box 266
2170 AG Sassenheim
The Netherlands
work:  [phone]   9.00-17.00 CET
home:  [phone]:00-23:00 CET
email: 2:281/521 or 2:281/515.3
email: [e-mail]
       [e-mail]
       ugw.utcs.utoronto.ca!rulgl.LeidenUniv.nl!FTHSMULD
TBSCAN, TBRESCUE, TBSCANX, Thunderbyte card

Mikael Larsson
Virus Help Centre
Box 7018
S-81107  SANDVIKEN
SWEDEN
Phone    : [phone]
Fax      : [phone]
BBS      : [phone] (HST)
FidoNet  : 2:205/204
VirNet   : 9:461/101
SigNet   : 27:5346/108 (soon)
Email    : [e-mail]

Virus Test Center, Faculty for Informatics
University of Hamburg
Schlueterstr. 70,  D2000 Hamburg 13, FR Germany
Prof. Dr. Klaus Brunnstein, Simone Fischer-Huebner
Contact: Margit Leuschner (VTC, secretary)
Tel: [phone] (KB), -4175 (SFH), -4162 (ML)
Email (EAN/BITNET): [e-mail]
Computer Virus Catalog (MS-DOS, Mac, Amiga and Atari)

Worldwide Software Inc.
20 Exchange Place, 27th Floor
New York, NY   10005
USA
212-422-4100
Telecopier 212-422-1953
[e-mail]
Vaccine Version 3.20 - Anti-Viral Software.



=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 105]
******************************************
VIRUS-L Digest   Thursday, 20 Jun 1991    Volume 4 : Issue 106

Today's Topics:

Re: Virus scanners (PC)
Questons about "Disinfectant" are ANSWERED.. Thanks (Mac)
virus detection by scanners ? (PC)
re: FSP and sales figures (was: Into the 1990s)
Int 24 virus info needed (PC)
Re: Checksumming
How viruses actually spread
Review of Victor Charlie (addendum) (PC)
Spanish Virus/Telefonica (PC)
Re: Scanning infected files (PC)
Re: joshi & vsum & f-prot & ll format (PC)
Re: virus detection by scanners ? (PC)
Requirements for Virus Checkers (PC)
Re: Interesting interaction ( VIRx & SCAN ) (PC)

is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

--------------------------------------------------------------------------------

Date:    18 Jun 91 11:53:35 -0400
From:    "David.M.Chess" <[e-mail]>
Subject: Re: Virus scanners (PC)

>Date:    Mon, 17 Jun 91 13:05:00 -0400
>From:    Al Woodhull <[e-mail]>

>The new files contain all of the infected code and so are
>good test targets, but since there is no way to execute the infected
>code it is essentially just a block of data.

They aren't necessarily good test targets.  "Bulk" scanners (like
IBM's), that look through every byte of every file for patterns, will
identify them as infected, but scanners that look at, for instance,
specific areas based on the file's entrypoint will not see them as
infected, even if they work fine on actually-infected files.  I
believe Alan Solomon's Anti-Virus Toolkit (I may have the name wrong)
is of the latter kind, for instance.  So if a scanner doesn't see
those files as infected, it doesn't necessarily mean that it wouldn't
see a normally-infected file as such...

DC

------------------------------

Date:    Tue, 18 Jun 91 11:11:11 -0600
From:    James Firmiss <[e-mail]>
Subject: Questons about "Disinfectant" are ANSWERED.. Thanks (Mac)

Thanks for all the info...

 "Vaccine (TM) 1.0.1", "KillVirus", and "Kill WDEF - virus INIT" have
been cast into our pit of obsolete & useless programs (with "Ferret"
and "Kill Scores").
  Disinfectant 2.4 and it's init are on all our MACs.
  Sam Intercept is on all of them too.  I hear it requres some sort
of password to remove it.  I've never tried to but I don't think anyone
here remembers what the password is.  I'll have to RTFM (if I can FIND TFM).


 + -  - +   |... P_lasma         --- James Firmiss     (Foxx Fox) ---
  - + +  -  |... S_ource         --- [e-mail]         ---
 +  +  - =====>+ I_on            --- Univ. of Wisc. Madison       ---
  -  +  -   |... I_mplantation   --- Materials Science Program    ---
 - + - + -  |..._______________________________________________________
         "Beep.  Beep Beep.  Beep Beep."  -  vi editor

------------------------------

Date:    18 Jun 91 13:05:32 -0400
From:    "David.M.Chess" <[e-mail]>
Subject: virus detection by scanners ? (PC)

>From:    [e-mail] (Hermann Stamm)
>Date:    07 Jun 91 14:33:23 +0000

>I have a few questions concerning detection of virii in general and
>1701 in special.

The main thing you've discovered here is that scanners only reliably
detect the viruses that they know about.  If you create a new virus
(from scratch, or by modifying an old one), it's very likely that some
scanners will no longer detect it.  No big surprises there!

>First of all, I hope that only good guys are on this list, because the
>remarks made here would otherwise result in hundreds of newly virii.

Almost certainly a false hope; there's no reason to think that no
virus writers are reading this.  On the other hand, I think they
already understand the principle!  One could have wished you'd been a
little less explicitly helpful to them, but I don't it'll hurt, at
least in the long run.

> - what other scanner should I try for these versions ?

Some scanners may be "lucky", and see your home-grown variants as
infected.  IBM's Virus Scanning Product, for instance, will recognize
the first of your monsters as a variant of the 1701.

> - is it true, that any scanner must try to look at the
>   semantics of such decoders, and not at the shape ?
>   (undecidable problem ?)

Yep, deciding whether or not a given program is a virus is definitely
undecidable.  Fred Cohen proved that awhile back.  So if you take some
existing virus, and make some changes to it, the question of whether
or not the result is still a virus is not one that *any* program is
going to get right all the time.  Scanners reliably detect only
*exactly* the viruses they know about, not variants that you (probably
unwisely) choose to create.

> - which systems are good by looking at the length of
>   files and reporting differences ?

Any good modification-detection program will look at the *contents* of
files (not just the length), and tell you what's changed.  Of course,
if you want to be able to trust the result, you have to get the
machine into a known state first (cold-boot from a trusted floppy,
don't run anything from the suspect hard disk).

> - Is the following behaviour possible for a virus:
>
>   After getting resident, it forces to do a warm-start
>   with ctrl-alt-del, and then it copies itself to all
>   .com-files encountered during rebooting
>   (like command.com, ...).
>
>   I think, that this is the way most of my .com-files
>   were infected.

A virus could certainly do that, but the 1701 doesn't.  Most likely it
infected something in the autoexec, so that the next time you booted,
it got control early, and then infected everything else executed
thereafter (that's how the 1701 works; it infects every com executed
after you run the first infected one).

DC

P.S. Assume that anything you post in public will be read by
     large number of virus authors.   Please *don't* post
     live virus code, or suggestions for improvements to
     existing viruses!   *8)

------------------------------

Date:    Tue, 18 Jun 91 13:24:44
From:    microsoft![e-mail]
Subject: re: FSP and sales figures (was: Into the 1990s)

>From:    [e-mail] (A. Padgett Peterson)

(Sorry for the delay...off line for a while)

>Ross: we seem to be cross communicating. In our shop we do not use "pre-
      >installed" copies, no two machines are alike anyway & we are running
      >everything from DOS 2.0 up. On installation, the package we use takes
      >3-5 minutes to take a "snapshot" of the PC and record every executable
      >on it during installation.

So, then, you have to install the program on each machine.  Taking
that "snapshot" is a good idea, but still has problems if you use a)a
new seed on each machine and b) store that seed someplace where it can
be seen by "the bad guy".

If someone is going to subvert the code, they're gonna subvert the code
and there's nothing we can do about it.  It's not as if DOS were a real
operating system -- it provides no real protection and simply putting
more and more layers of "feel-good-and-warm-and-fuzzy" dressing on DOS
simply makes a person *feel* better, but provides them with nothing.

If somebody wanted to mcreate a virus that gets around my stuff and the
code of everybody else out there, they probably could.  Targetting my
code is sorta silly: it's too easy to simply go right out to the disk
controller if you really needed to.

>Only if the "bad guy" knows where it is stored and if the offsets are
>the same on every machine - one of the drawbacks to
>"pre-installation". If you cannot ensure the physical integrity of the
>machine all bets are off. It would take a complex and specifically
>targetted piece of software to be able to determin that you were there
>(and not some other routine) and bypass it - not for an amateur.

Right.  So, if they're targetting my code, no protection will suffice,
if they are not targetting my code, why bother making things more
complex.  Your mileage may, of course, vary.

> One
>of the problems is that at present there is a single criteria for
>judging PC protection programs: the number of viruses it detects.  In
>actuality, this is one of the lesser threats that a full package
>should take care of.

Well, the efficiency of a package in stopping viral infections has yet
to have any scale to measure it by.  When such a scale exists, all the
vendors will be climbing to the top of that heap, too.

Ross

(My views, not Microsoft's)

------------------------------

Date:    Tue, 18 Jun 91 14:26:47 -0400
From:    Alex Nemeth <[e-mail]>
Subject: Int 24 virus info needed (PC)

I remember something about an INT 24 virus that was discussed several
months ago. could someone pleas send me some info on it, or tell me
which back issue of Virus-L where i might find more.

Thanks

Alex Nemeth
[e-mail]
[e-mail]

------------------------------

Date:    Tue, 18 Jun 91 15:17:36 -0400
From:    [e-mail] (A. Padgett Peterson)
Subject: Re: Checksumming

>From:    Y. Radai <[e-mail]>

>  Mike Lawrie writes:
>>                         ... sooner or later this scenario [infecting
>>files by performing SCAN while a virus like Plastique is in RAM] will
>>re-occur, as you will get hit with a similar type of virus that McAfee
>>has not yet catered for, even if you have their very latest version.
>Right;

First, organizations have been woefully lacking in training of
personnel expected to deal with malicious software (a management
problem). Our technicians get two days of targetted training before
being certified to respond to suspected viruses.

That said, since employees are instructed to power down and quarentine
any PC suspected of having a virus, the first action after questioning
the employee for symptoms is to cold boot from a write-protected
floppy and check the system out in that manner including a "scan" of
the disk and examination of the MBR and DOS Boot Record

Only if that comes up negative is the PC allowed to boot itself. At
this point the system integrity is repeatedly validated using
MEM/DEBUG and CHKDSK to determine if something is trying to go
resident.

At this point, McAfee's SCAN is often used in a different way: the
command "SCAN NUL /M" results in only memory (no files) being checked
for all viruses it knows about. If this fails then file comparisons
are done and the audit trails are checked (all PCs including employees
home machines are authorized to use a site-licensed checksumming
program).

Again a layered approach by trained personnel is necessary to protect
against the sort of global disaster mentioned (incidently, during my
training session at the CSI Conference in Denver, I thoroughly
infected the demo PC with the 4096 only to discover that there was no
5 1/4 boot floppy to use for recovery - Had several 3 1/2s for the
laptop, but no 5 1/4s.  Entertaining.)

BTW the McAfee product .DOCs do mention in several places the
advisability of booting from a known clean, write-protected floppy
first.

>>A checksummer gives you no
>>security whatsoever, because it does not prevent a viral infection.

>True, a checksummer does not prevent infection, but at least it can
>*detect* infections, and that's a lot better than no security at all!!

Depends on the checksummer - the one we use performs the checksum
routine on any program presented for execution. If the program is not
known to the audit trail, a screen warns the user that the program is
unknown.  Depending on the setting, the user may or may not be
permitted to execute the program. I suppose that this really comes
under the heading of access control but should be part of any
integrity management solution.

>... a program which prevents infections through floppy boots (to
>be mentioned soon)...

I believe that VSHIELD protects from hot-boots now - do not believe
that prevention from cold boots can be done without hardware or
special BIOS.  My next project now that DISKSECURE is essentially
complete will be a small addition to warn the user on boot if a floppy
is in the drive - should not be difficult or require much code (trap
cntrl-alt-del, check for floppy, write warning message, loop for
response), several viruses make use of this technique already so it
cannot be too difficult (famous last words).

                    Cooly (a/c working again)

                            Padgett

------------------------------

Date:    Wed, 19 Jun 91 00:50:00 +0000
From:    William Hugh Murray <[e-mail]>
Subject: How viruses actually spread

>Of course I don't do much with shareware or BBS downloading which is
>where I imagine most of the problems are.

Along with many others, you imagine an untruth.  Both PC and Mac
viruses spread by sharing of machines and diskettes.  They might have
been spread by BBSs but they have not been.  They might have been
spread by shareware, but they have not been.

Regular readers of this forum are aware of this, but it bears
re-stating, particularly in the face of specualtion to the contrary.

The most successful viruses infect boot sectors of diskettes,
partition tables or boot sectors of hard drives, and go resident,
i.e., they are TSRs.  They spread when users permit strange diskettes
to be inserted in their machines, or when they put their diskettes in
machines that they did not themselves boot from a known source.  While
they can and do spread marginally in other ways, this high-risk
behavior accounts for their current success.

------------------------------

Date:    Tue, 18 Jun 91 18:23:54 -0700
From:    [e-mail] (Rob Slade)
Subject: Review of Victor Charlie (addendum) (PC)

For those who want to "try before you buy", Victor Charlie version 3.2 is
a "freeware" demo version.  The file VC3-2.ZIP should be available on
BBS's, and is posted on SUZY.

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Wed, 19 Jun 91 04:14:00 +0000
From:    Ben Zajac <[e-mail]>
Subject: Spanish Virus/Telefonica (PC)

Recently, a virus was discovered at Oxford University, Oxford
(England) and the City Univerity at London (England).  It has been
named, "Spanish Telecom," and also, "Telefonica."

According to information that I have received from the UK, the
virus does not kick in until after the system has been booted up
400 times.

The code reportedly contains the following message:

             "Menos tarifes y mas servivios"

    Which means: "Lower tariffs, more service"

Damage -- When triggered, destroys (overwrites) hard disks.

Detection:

     The virus is in *.COM files and boot sector.

     Pattern:

     Header 1 - 881D 8200 83FB 0074 188F 5500 B2; OFFSET 034H

     Header 2 - 83ED 09BE 2001 03F5 FC86; OFFSET 024H

     Boot Sector -

                8A0E EC00 8E700 0003 F18A 4C02 8A74 03C3;OFFSET 083H

I have not personally examined this virus, however the I have no
reason to doubt the source.

           Bernard P. Zajac, Jr.
           MCI MAIL - [e-mail]

------------------------------

Date:    19 Jun 91 08:26:44 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: Scanning infected files (PC)

>Good question, but: wouldn't it be possible for the stealthy virus to
>trap the sector I/O and "fix" it to also hide its tracks?

Not only possible - it has already been done.  At least one virus,
simply known as INT13 does just this.

- -frisk

------------------------------

Date:    19 Jun 91 08:30:32 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: joshi & vsum & f-prot & ll format (PC)

[e-mail] (Terry N Reeves) writes:
>    f-prot must be intended to work - "cured" - so can the author
>speak to this?

As far as I knew, F-DISINF should have been able to remove the Joshi virus.
I'll look into this right away and check what the problem is.

- -frisk

------------------------------

Date:    19 Jun 91 08:22:54 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: virus detection by scanners ? (PC)

[e-mail] (Hermann Stamm) writes:
>  - what other scanner should I try for these versions ?

It does not matter - you will get practically the same results.  My
scanner may detect some of those SCAN missed or vice versa, but that
is not important.

What is important is that you cannot expect a scanner to detect a
modified virus. It may work, or it may not, but there is absolutely no
guarantee.  A scanner is designed to detect existing viruses, not new
ones or new variants of older viruses, although some scanners may
detect some new variants of some viruses.

>  - is it true, that any scanner must try to look at the
>    semantics of such decoders, and not at the shape ?

Well, if it looked at something else, it would not be a scanner.... :-)

Don't misunderstand me - there are programs which may look at the 1701
virus, or some of your modified variants, and report something like:

    This program seems to cotain additional code at the end,
    which starts by performing decryption of itself. This is
    typical of a virus.

But, a program like this is not a scanner - it is a generic analysis
tool, unable to identify viruses - it just reports anything
"suspicious".

>  - which systems are good by looking at the length of
>    files and reporting differences ?

Differences between what ?

>  - Is the following behaviour possible for a virus:
>
>    After getting resident, it forces to do a warm-start
>    with ctrl-alt-del, and then it copies itself to all
>    .com-files encountered during rebooting
>    (like command.com, ...).

No - it is not possible.

------------------------------

Date:    Tue, 18 Jun 91 23:11:30
From:    microsoft![e-mail]
Subject: Requirements for Virus Checkers (PC)

>From:    Robert McClenon <[e-mail]>

(Sorry for the delay...offline for a while)

>Excuse me, but I use Virex-PC, which is Ross's product.  I do
>occasionally need to remove it, not to troubleshoot IT, but because
>something is incompatible with it.  One commercial game requires 540K
>of FREE memory, not counting MOUSE.SYS, which it uses, and can't fit
>if Virex-PC is installed.

The next version of the code runs the resident virus checker in 608
bytes, Robert.  I think I can shave about 150 more off of that....

>  A third-party fax board program has TSR
>conflicts with Virex-PC.  I don't know what it is doing, but it tries
>to take over the same interrupts as Virex-PC and the results are
>unpredictable.  (Sometimes it refuses to run.  Sometimes it crashes.)

Have you called tech support @ Microcom (919-490-1277) and told them
about it?  We might have a fix someplace around, or can attempt to
figure out what's wrong and fix it in the next release.

EVERYBODY: Never accept a problem with a piece of code: the vendor
can't fix it if they don't know there is a problem.

Ross

------------------------------

Date:    Wed, 19 Jun 91 16:30:21 +0000
From:    [e-mail] (Ken Forward)
Subject: Re: Interesting interaction ( VIRx & SCAN ) (PC)

[e-mail] (Rob Slade) writes:
> Noted an interesting interaction between two antivirals the other day,
> and finally tracked it down.  If VIRx 1.4 is run before SCAN 77, SCAN
> will "detect" the presence of the 3445 and Doom 2 viri in memory and
> refuse to run.

Tried this out for myself; no 3445 or Doom 2, but Taiwan3 [T3] was
"found" in memory.  Has anyone experienced any other false positives
with this combination ?

Cheers,
- ---------------------------------------------------------------------------
     Kenneth Forward             |    "...don't plant your bad days,
     MUN Dept of Physics         |        they grow into weeks..."
     [e-mail]    |                    -Tom Waits-
- ---------------------------------------------------------------------------

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 106]
******************************************
VIRUS-L Digest   Thursday, 20 Jun 1991    Volume 4 : Issue 107

Today's Topics:

Re: virus detection by scanners ? (PC)
Pro vs Reactive Protection (PC)
Re: Boot sector viruses on IDE drives (PC)
FPROT116 is on BEACH (PC)
Can such a virus be written .... (PC)
Boot sector viruses on IDE drives (PC)
doom 2 (PC)
protecting mac files via locking (Mac)
Stoned & Novell? (PC)
VSHIELD and Warm Boots (was Re: Checksumming) (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    19 Jun 91 15:53:28 +0000
From:    [e-mail] (Arthur Rubin)
Subject: Re: virus detection by scanners ? (PC)

I'm somewhat suspicious of any code with the following instructions:

E80000            CALL   (next instruction)

(except that some linkers produce that for a near call to an
unsatisfied external, and it could be required for
ROM/position-independent code that needs to access data)

3134              XOR    [SI],SI

(except that that is ASCII '14')

There doesn't appear to much else fixed in there except

B*8206            MOV   ??,0682

which could also be changed if you have a spare byte, which you can
get in your last try.  (Details omitted -- let's not make it TOO
easy.)

I hope some virus scanners have a signature for 1701 in the encrypted
portion.

- --
[e-mail] [e-mail] [e-mail] (personal)
[e-mail] (work)
My opinions are my own, and do not represent those of my employer.

------------------------------

Date:    Wed, 19 Jun 91 12:51:57 -0400
From:    [e-mail] (A. Padgett Peterson)
Subject: Pro vs Reactive Protection (PC)

In recent issues, there has been considerable outcry concerning the
"unremovable" infections that seem to plague many users and that the
generic anti-viral packages are not able to deal with them.

To repond, I have one PC (an XT) that has been infected with everything
possible yet recovery is trivial, it has been low-level formatted only
once (when it was delivered), and high-level formated an equal amount.

Of course, being an "infection" machine, it has some special qualities,
but none that I do not practise on my home machines as well.

For one, before every infection, the machine is fully backed up including
MBR, hidden sectors, DOS Boot Record, and both FATs (Bernoullis help &
it is only a 10 MB disk), however the special portions mentioned all fit
on a bootable 360k floppy and are self-restoring (similar disks exists
for each of the other machines except I usually do not save the FATs on
these).

This process has a number of advantages but does require a "recovery" disk
(preferably two) for each PC, however the process is nothing a good tech
cannot accomplish in five minutes using nothing more sophisticated than
DEBUG - less if automated, then the longest delay is SYSing the recovery disk
with the OS in use & copying any special drivers in use.

Unfortunately for many users, this MUST be done with an uninfected machine.
Since many call for help only after infection, this pro-active activity is
useless at that point.

Currently, the tool of choice seems to be McAfee's CLEAN, a generic
tool that is designed along the lines of the Oath of Hippocrates:
"First, Do No Harm". Even if it recognizes the virus (e.g. MusicBug),
and knows where the it stores the Boot Record, it must verify each
step of the way (is this really the mk 1 MusicBug or might it be a
clone ? Does it look like register values in the proper location ?
Does the retrieved sector look like a real Boot Sector ? Do the table
values match this disk ?) If any step fails, a generic disinfector
MUST refuse to continue. (those who have experienced total loss as a
result of certain "doctor" programs please raise your hands).

One of the things that can cause such problems are multiple
infections, another is the sheer diversity of boot record/MBR codes -
last year a european testing program recorded a PNCI boot record as
suspect, early versions of PC-Tools had an incredible boot record that
is the only one I have ever seen that would work with both MS-DOS and
PC-DOS. Sometimes it is hard to tell the good guys from the bad guys.

Recently, I have seen reports that some viruses use code that is so
close to each others that many scanners cannot tell the difference yet
the EMPIRE and the AZUSA need radically different cures if the
original table was not backed up somewhere off-PC (have had reports of
EMPIRE being reorted as AZUSA/Hong Cong).

In this case, you are just going to have to re-read your back issues
of Virus-L for the identifiers of each strain and the manual removal
methods that should have appeared along with the report (or soon
after).

Just to add one final note of cheer: as the strins keep increasing,
the likelyhood of misidentification will continue to increase but for
me, I would rather have a "false positive" to alert me to changes than
"false negatives" any day. After all, we have the tools, training, and
backups to handle just about anything but we "can't fix it if we don't
know its broke".
                    Cooly,
                        Padgett

------------------------------

Date:    19 Jun 91 14:58:45 -0500
From:    [e-mail]
Subject: Re: Boot sector viruses on IDE drives (PC)

[e-mail] (John Boyd;LAHDI) writes:

> not possible on an IDE drive.  So the question becomes; for an IDE
> drive, what DO you do to get rid of a boot sector virus?

McAfee Associates ( The ScanV folks) have a program that will remove a
boot sector virus.  Its name is Clean-up, They also have another
called Mdisk.  I'll vouch for it, as It removed the Stoned virus from
my Seagate ST-1144A IDE drive without a hitch.  I don't know of a FTP
location, But it can be obtained from the authors BBS at 408-988-4004.

------------------------------

Date:    Wed, 19 Jun 91 11:22:27 -0500
From:    [e-mail] (John Perry)
Subject: FPROT116 is on BEACH (PC)

Hello Everyone!

        FPROT116.ZIP is now available on BEACH.GAL.UTEXAS.EDU. Come on
by and pick up a copy.

                              John Perry KG5RG

You can send mail to me at any of the following addresses:

Internet : [e-mail]
UUCP     : nuchat!farwest!perry

------------------------------

Date:    20 Jun 91 09:36:40 +0000
From:    Steven van Aardt <[e-mail]>
Subject: Can such a virus be written .... (PC)

  Is it possible to write a PC virus which installs itself whenever
you place an infected disk in the drive and do a DIR command ?

Steve.

- --
  ---------------------------------------------------------------------------
  -       JANET E-mail : [e-mail].p4 (Steven van Aardt)       --
  -- Warning this user has been designated for termination on the 21.6.91  --
  ---------------------------------------------------------------------------

------------------------------

Date:    Thu, 20 Jun 91 09:59:25 -0400
From:    Ronnie Judd <[e-mail]>
Subject: Boot sector viruses on IDE drives (PC)

[e-mail] (John Boyd:LAHDI) writes;
> It recently occured to me that we get rid of most boot-sector viruses
> by routinely doing a low-level format on a drive.  However, this is
> not possible on an IDE drive...

Seems I keep seeing over and over on this list that one *almost never*
has to do a low level format to remove boot sector viruses.  However
on the question of how does one format an IDE drive there are programs
out there that will do such a thing.  I recently upgraded a couple of
Compaq machines and found Disk Manager 4.0 did the trick just fine.
So if you feel that you *absolutely must* low level format to get rid
of the offending virus give it a shot.

Ronnie N. Judd            |    _ _ _           / | BITNET: RNJUDD@SUVM
Dept. Civ/Env Engineering |  / (o o)  _ _ _ /   | Phone:  [phone]
220 Hinds Hall            | |_/|   |_|      |   | FAX:    [phone]
Syracuse University       |    (._.)||_ _(  /    | A failure is a chance
Syracuse, NY 13244-1190   |      U _||   _||     | to start again smarter
       (Of course these are my opinoins, no one else wants them!)

------------------------------

Date:    Thu, 20 Jun 91 08:16:55 -0700
From:    [e-mail]
Subject: doom 2 (PC)

It would appear to me that VIRx 1.4 isn't cleaning up after itself.
You guys just ran accross different bits of code because of different
ares of RAM being used to store the search strings.

I state this obvious point, to make a point. This would seem slopy
code on two points: One that VIRx doesn't clean up after itself,
allowing other programs to find it's code fragments, is of course a
major concern to the users of the program. (Should also be of great
concern to the authors, but no matter for that for now..)

The second point is that it's a security problem for all computer
users.  Consider: It's simplicity itself for someone who can write a
virus to tear apart the non-encrypted VIRx code and determine the
search strings used in VIRx.

Now, this in itself wouldn't be a problem, I guess, but consider that
what SCAN saw, were the search strings that VIRx was using.... meaning
they're using the SAME strings. Based on this info, anyone who wanted
to, could, in theory, modify the virus enough that the string would no
longer bee caught by the current search strings.

Encrypting the search strings in your code, therefore is always a good
idea, as is cleaning up the mess your program makes in RAM. VIRx,
apparently doesn't address these two points.

------------------------------

Date:    Thu, 20 Jun 91 13:41:57 -0400
From:    Lee Ratzan <[e-mail]>
Subject: protecting mac files via locking (Mac)

Aplication locking on a Macintosh prevents a file from accidentally
being destroyed (trashed) and to some extent from being altered.
A user wants to know if locking Disinfectant on a hard disk will
prevent it from being itself infected from a virus emanating
from an infected floppy.

The issue is whether we can trust a resident locked copy of
Disinfectant to remain clean even if the hard disk on which it resides
becomes infected.

I have advocated that since we have no automatic virus checking
software which is activated upon disk insertion or start up and since
anyone can use the machine, the only way to be absolutely certain that
integrity has not been compromised each morning is to boot up first
with a trusted disk and run the trusted disk copy of Disinfectant
against the hard disk files.

Comments?

Lee Ratzan

------------------------------

Date:    Thu, 20 Jun 91 12:18:17 -0600
From:    [e-mail] (Richard W Travsky)
Subject: Stoned & Novell? (PC)

Does anyone have any information on Stoned and Novell 3.X networks?
Like can a Novell server pick up Stoned (or any other boot sector
infector)?  I've some information that indicates it can but not much
more than that.  Tales, experiences, caveats?  Please reply by email,
I need info ASAP.  Many many thanks!

Richard Travsky
Division of Information Technology     RTRAVSKY @ CORRAL.UWYO.EDU
University of Wyoming                  (307) 766 - 3663 / 3668

------------------------------

Date:    Thu, 20 Jun 91 19:23:00 +0000
From:    [e-mail] (McAfee Associates)
Subject: VSHIELD and Warm Boots (was Re: Checksumming) (PC)

[e-mail] (A. Padgett Peterson) writes:

(a lot of stuff deleted here...)
>I believe that VSHIELD protects from hot-boots now - do not believe
>that prevention from cold boots can be done without hardware or
>special BIOS.  My next project now that DISKSECURE is essentially
>complete will be a small addition to warn the user on boot if a floppy
>is in the drive - should not be difficult or require much code (trap
>cntrl-alt-del, check for floppy, write warning message, loop for
>response), several viruses make use of this technique already so it
>cannot be too difficult (famous last words).

VSHIELD traps warm (hot) boots (aka Ctrl-Alt-Dels, Three Finger
Salutes) to check the floppy drive and then the hard disk for boot
sector and partition table infecting viruses.  If a virus is found,
VSHIELD displays it's "found virus X in area Y" message and prompts
the user to power down and boot off a clean system disk.  If no virus
is found, then VSHIELD reboots the system as normal.

Some XT systems apparently have problems with this, causing a reboot
to take a long time (5 minutes or more).  If so, the option can be
turned off by using the /NB (No Boot) checking.

Regards,

Aryeh Goretsky
McAfee Associates Technical Support

- --
McAfee Associates     | Voice [phone]    | [e-mail]
4423 Cheeney Street     | FAX   [phone]    | (Aryeh Goretsky)
Santa Clara, California     | BBS   [phone]    |
95054-0253  USA         | v.32  [phone]    | [e-mail]
ViruScan/CleanUp/VShield | HST   [phone] | (Morgan Schweers)

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 107]
******************************************
VIRUS-L Digest   Monday, 24 Jun 1991    Volume 4 : Issue 108

Today's Topics:

Weird things in our LAN! (Mac)
Re: Can such a virus be written .... (PC)
Re: Can such a virus be written .... (PC)
DesasterMaster 2
Re: Interesting interaction ( VIRx & SCAN ) (PC)
Interesting interaction (PC)
doom 2 (PC)
Re: Hypercard Antiviral Script? (Mac)
Re: Can such a virus be written .... (PC)
Disk Killer Virus (PC)
Re: Software Upgradable BIOS (PC)
Re: protecting mac files via locking (Mac)
Thanks for help (virus papers)
joshi & vsum & f-prot & ll format (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Fri, 21 Jun 91 01:32:11 +0000
>From:    [e-mail] (Bob Marley)
Subject: Weird things in our LAN! (Mac)

We have a small problem in our LAN here. We have a dedicated server
(SE/30) serving about 30 pluses (1meg mem etc). We have to start them
off of workstation disks. This has been happening periodically
throught the year, every once and a while one of the workstation disks
appears to be turned invisible. All the files are GONE. They are
there, it says that the space is being used, and the disks boot etc.
They are NOT invisible however. I have gone in with absolutly every
file/disk/etc utility to look for them. Resedit, disktools, the works.
The only invisible file on any of the disks was the (obviously)
desktop. Now, the other day, we got one of our pluses back that we had
loaned out, and we discoverd that on the 20meg hard drive, it happend
AGIAN. ALL the files invisble. The person who had it was freaked, for
he thought he had deleted the entire harddrive. We have checked for
viruses, and havent found any... It is just plain WEIRD. Anyone have
any ideas on what could be done, to fix this before it hits our server
and makes EVERYTHING there invis?  Help!

------------------------------

Date:    Fri, 21 Jun 91 17:43:00 +1200
>From:    "Mark Aitchison, U of Canty; Physics" <[e-mail]>
Subject: Re: Can such a virus be written .... (PC)

[e-mail] (Steven van Aardt) writes:
>
>   Is it possible to write a PC virus which installs itself whenever
> you place an infected disk in the drive and do a DIR command ?

Yes. But on a PC this requires certain conditions, which mean it
probably wouldn't spread very far.

Mark Aitchison, Physics, University of Canterbury, New Zealand.

------------------------------

Date:    21 Jun 91 09:39:26 +0000
>From:    Doug Krause <[e-mail]>
Subject: Re: Can such a virus be written .... (PC)

[e-mail] (Steven van Aardt) writes:
#
#  Is it possible to write a PC virus which installs itself whenever
#you place an infected disk in the drive and do a DIR command ?

Doesn't STONED act that way?

Douglas Krause                     One yuppie can ruin your whole day.
- ----------------------------------------------------------------------
University of California, Irvine   Internet: [e-mail]
Welcome to Irvine, Yuppieland USA  BITNET: [e-mail]

------------------------------

Date:    Fri, 21 Jun 91 11:45:29 +0000
>From:    [e-mail] (Tobias Ruland)
Subject: DesasterMaster 2

high all!  does anybody know the amiga "desastermaster 2"-virus how it
works and what it does?

              cu
                      Tobias

------------------------------

Date:    Thu, 20 Jun 91 17:23:19
>From:    [e-mail]
Subject: Re: Interesting interaction ( VIRx & SCAN ) (PC)

>From:    [e-mail] (Ken Forward)
>
>[e-mail] (Rob Slade) writes:
>> Noted an interesting interaction between two antivirals the other day,
>
>Tried this out for myself; no 3445 or Doom 2, but Taiwan3 [T3] was
>"found" in memory.  Has anyone experienced any other false positives
>with this combination ?

It goes to show that the viral strings used in Program A might also be
used in Program B.  The string database is large enough that it
probably spanned more than a few DOS buffers: depending on what
buffers were used by subsequent code, different portions of the string
database might be left in different areas of memory, thereby those who
share our strings will have different "hits" at different times.

The new cut of VIRx with new strings added (a bunch) and some bug
fixes is due out any second...

Ross

------------------------------

Date:    Wed, 19 Jun 91 18:53:21
>From:    [e-mail]
Subject: Interesting interaction (PC)

>From:    [e-mail] (Rob Slade)
>
>Noted an interesting interaction between two antivirals the other day,
>and finally tracked it down.  If VIRx 1.4 is run before SCAN 77, SCAN
>will "detect" the presence of the 3445 and Doom 2 viri in memory and
>refuse to run.

Sigh.  Color me dumb.  I forgot to call the zap_virus_strings()
routine under certain conditions, so I left a lot of strings in
memory.  It looks like the McAfee scanner uses some of the same
strings we do...

This has been fixed in the next release of VIRx, due out in a few
days.  Lots of other good stuff in the new one, too.

Ross

- ------------------------------

Date: Wed Jun 19 18:53:21 1991
>From: [e-mail]
Subject: joshi & vsum & f-prot & ll format (PC)

>From:    [e-mail] (Terry N Reeves)
>
>Vsum still says no utility will remove joshi and that low
>level format is required...

Vsum is totally wrong.  Virex-PC has been able to cure Joshi for quite
a while (> six months, at least).

>    Is their a utility Ms Hoffman? perhaps yuou just don't want to
>admit it because McAffe's can't? (i have not tried McAffee but I
>assume she'd say if his did.)

Interesting idea....

Ross

------------------------------

Date:    Thu, 20 Jun 91 19:34:27
>From:    [e-mail]
Subject: doom 2 (PC)

>From:    [e-mail]
>
>It would appear to me that VIRx 1.4 isn't cleaning up after itself.
>You guys just ran accross different bits of code because of different
>ares of RAM being used to store the search strings.

(Will I ever live this down?  One mistake and *bingo!* all over the
place.  Sigh.)

>The second point is that it's a security problem for all computer
>users.  Consider: It's simplicity itself for someone who can write a
>virus to tear apart the non-encrypted VIRx code and determine the
>search strings used in VIRx.

Actually, the strings are trivially "encrypted" to prevent the image
out on disk from triggering who-knows-how-many other scanners out
there. The image I left in memory is *after* the decryption.  Why, you
might wonder, don't I use a more complex en/de-cryption scheme?

The answer is simple: whatever for?  The bad guys can certainly break
whatever coding scheme I use, thereby using the string list just as if
it were not encoded at all.  Since it is trivial to make a program
that can determine what string a scanner is using, using complex
schemes serves no purpose except to a)give more areas for weird bugs
to show up, b)a tad of time spent by *every* user in the decrypt
routine.

The signature a scanner uses is of no use to a bad guy unless he or
she already has the subject virus on hand, in any case.

>Now, this in itself wouldn't be a problem, I guess, but consider that
>what SCAN saw, were the search strings that VIRx was using.... meaning
>they're using the SAME strings. Based on this info, anyone who wanted
>to, could, in theory, modify the virus enough that the string would no
>longer bee caught by the current search strings.

In many viruses (virii?) there is only a small area that you can use
to figure out a decent signature.  Two scanners using a similar area
should not be considered unusual.  One of my favorite areas to use is
the "Are you there?" call most resident viruses use: I assume most
others use it, too.  For viruses that I don't have on hand, I use the
Virus Bulletin list: I would presume that the bad guys have as much
access to that list as McAfee's scanner programmers do, too....

>Encrypting the search strings in your code, therefore is always a good
>idea, as is cleaning up the mess your program makes in RAM. VIRx,
>apparently doesn't address these two points.

Wrong on both counts.  It is interesting, though, that about 20 beta
testers did not find that problem at all....

One of the interesting things: Microcom, the people who publish and
market my code, is expressly forbidden from using McAfee products by
the vendor itself.  This is interesting since Microcom was, until
recently, a member of the so-called CVIA, paying their dues and
getting *absolutely* none of the privs supposedly associated with that
membership.

Ross

------------------------------

Date:    Thu, 20 Jun 91 23:53:45 +0000
>From:    [e-mail] (Michael Kerner)
Subject: Re: Hypercard Antiviral Script? (Mac)

Actually, Eric, you will find that there appears to be a bug in 2.0v2,
and you can intercept SETs that are SEND'ed (sorry, but
SEN(t)D?)...anyway, having not tried this trick in 2.1, I don't know
if it will work...and, as usual, I wouldn't trust the documentation -
try looking at the params of the SET command.  As far as the rest of
this discussion goes, I have been playing with fire & my own viri (for
test purposes, folks, so relax...then again, with the couple of times
I've been corrected, these critters wouldn't do much harm anyway...)
and as long as LockMessages is set, and as long as one checks the
script of stack xxx before opening it, it's essentially impossible to
infect yourself by opening a stack - ASSUMING YOU CHECK THE SCRIPT OF
THE STACK FIRST.

The code to scan a stack is essentially the same as the SearchScript
code that y'all will find in your HOME stack, only you have to modify
it to accept a file name (answer file...everyone remember now?...)
anyway, after you do that, the search string is "set the script of".
HOWEVER, it is possible that someone has the viri sitting in an XCMD
or XFCN which they invoke, so you should also check the resources they
have attached to their stack...so you see, it becomes a pain to simply
scan the stack script because you also need to scan the resources to
be effective.

Mike.
Mac Admin
WSOM CSG
CWRU
[e-mail]

------------------------------

Date:    Fri, 21 Jun 91 17:08:31 +0000
>From:    [e-mail] (Brian D. Howard)
Subject: Re: Can such a virus be written .... (PC)

[e-mail] (Steven van Aardt) writes:


>  Is it possible to write a PC virus which installs itself whenever
>you place an infected disk in the drive and do a DIR command ?

Yes.

You'd have to change command.com and have a dir.com or dir.bat just
sitting there.  I've actually manually done something like that as a
prank (stay away from me on april 1...)

(You asked merely if it was *possible*.  Now, do you think you've got
something like that going on?)
- --
"Hire the young while they still know everything."

------------------------------

Date:    Fri, 21 Jun 91 14:36:00 +0000
>From:    Jim Schenk <[e-mail]>
Subject: Disk Killer Virus (PC)

Hello,

Does anyone have information on the Disk Killer Virus?  (I've already
got Patricia Hoffman's VSUM - I need some more detailed info).
Running F-PROT 1.15A on a DTK 286 under MS-DOS 4.01 results in the
following:

        This boot sector is infected with the Disk Killer virus.
        Disinfect? Y

        Can not cure - original boot sector not found.

Any help would be greatly appreciated.

Jim Schenk
University Computer Services
Florida International University

Bitnet:         jims@servax
Internet:       [e-mail]

------------------------------

Date:    21 Jun 91 21:22:40 +0000
>From:    [e-mail] (Richard H. Miller)
Subject: Re: Software Upgradable BIOS (PC)

[e-mail] (Terry Ingoldsby) writes:

> It is not even necessary to place it under hardware control, rather if
> the hardware incorporates an interlock that requires a special,
> possibly unique, code, then the viruses could bash at it forever
> (almost) without success.
>
> For example if each machine thus manufactured were assigned a unique
> value in EPROM (which could not be read by the CPU), say of length 64
> bits, then the user could be queried, by the software upgrade program,
> to enter the key.  If the key matched, the EAROM would be modified,
> otherwise nothing would happen.

this is a nice though in theory, but in practical terms, would be a
logistical nightmare for sites which have a large number of PCs or
that swap components.  This would require that detailed records be
kept each PC and each time a motherboard is swapped or the BIOS is
replaced rather than updated.In all likelyhood, two things would
happen

1) The 'key' would be written on the PC which would give you the same
protection as hardware control.

2) Someone would loose their key and the BIOS chips would have to be
replaced.

Another approach is to use a lock mechanism with a key to update the
BIOS.  For the single user or sites which do not require central
configuration management, the key could stay in the PC [as it does not
in most cases.] For sites which do use central configuration
management, the key would be kept away from the PC to prevent BIOS
upgrades except under controlled circumstances

I do think that upgradeable BIOS under these circumstances is a good
idea. This is a concept which has been very successful in the larger
systems for quite a long time as would work well with necessary
controls. It would certainly be much easier to load the BIOS from
floppy for 1,000 PC's than to replace the BIOS PROMS.

- --
Richard H. Miller                 Email: [e-mail]
Asst. Dir. for Technical Support  Voice: [phone]
Baylor College of Medicine        US Mail: One Baylor Plaza, 302H
                                           Houston, Texas 77030

------------------------------

Date:    Fri, 21 Jun 91 23:46:32 +0000
>From:    [e-mail] (Michael Kerner)
Subject: Re: protecting mac files via locking (Mac)

NO!  ABSOLUTELY NOT TRUE IN ANY WAY, SHAPE, OR FORM.  IT IS IMPOSSIBLE TO
PROTECT A FILE BY LOCKING IT.  PERIOD.  ABSOLUTELY NOT.  IT DOESN'T HAPPEN.
The only way to protect a file is to have it on a locked volume.  Now I don't
know if SAM is beyond this, because I haven't tried it...yet (hey, c'mon,
I read newsgroups on Internet in what little free time I have between my job
at xxx and handling the lab here.  However, I have an "utility" which will
overwrite any resource in any file, and that's all the more specific I am
going to get about it because I don't want some amateur hack reading this
to get any ideas.  Saying that it can be done is bad enough - it encourages
the ones that don't know ... yet.  At any rate, file locking AND PROTECTING
(via some sector editor) do not stop this "utility" from working - no, it's
not ResEdit, but I haven't tried ResEdit, although I would assume that it
won't work.

So, there is NO WAY to stop a file on an unlocked volume from being written
to, changed, etc.

Sorry.

Mike.
Mac Admin
WSOM CSG
CWRU
[e-mail]

------------------------------

Date:    Sun, 23 Jun 91 22:11:24 -0500
>From:    Mac Su-Cheong <[e-mail]>
Subject: Thanks for help (virus papers)

Dear netters :

   About a month ago I had asked for help with virus papers. Here is the
original request :

>   I am looking for the following thesis :
>
>   F. Cohen, "Computer Viruses", Ph.D. Dissertation, University of Southern
>   California, 1986.
>
>   Can I get it from some anonymous ftp sites ? If no, how can I get it. I am
>trying to gather papers about viruses. Any help is appreciated.

   I have got several responses for the request. Someone suggest me to
get the books COMPUTE!'s COMPUTER VIRUSES and COMPUTE!'s COMPUTER
SECURITY, but I have not found them yet. Another one suggest me to log
on ftp.cs.widener.edu (192.55.239.132) but I can't find virus paper. A
nice guy find the paper in library and send me the abstract. Later I
have found some papers from the following anonymous ftp sites :
   cert.sei.cmu.edu      pub/virus-l/docs
   cs.toronto.edu        doc/pc-virus.notes

   There are many virus papers on the Magazine "Computers & Security",
but they are not collected in my local library :-(

   Especially thanks to Ralph Roberts, Alan Jones, Mark, and Malcolm.
They are so kind for doing such a lot to me. This is the first time I
write a summary.  If there is something wrong, please tell me. Thanks
for your time.

Mac Su-Cheong (MSC)
nckus089@twnmoe10
[e-mail]

------------------------------

Date:    Wed, 19 Jun 91 18:53:21
>From:    [e-mail]
Subject: joshi & vsum & f-prot & ll format (PC)

>From:    [e-mail] (Terry N Reeves)
>
>Vsum still says no utility will remove joshi and that low
>level format is required...

Vsum is totally wrong.  Virex-PC has been able to cure Joshi for quite
a while (> six months, at least).

>    Is their a utility Ms Hoffman? perhaps yuou just don't want to
>admit it because McAffe's can't? (i have not tried McAffee but I
>assume she'd say if his did.)

Interesting idea....

Ross

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 108]
******************************************
VIRUS-L Digest   Tuesday, 25 Jun 1991    Volume 4 : Issue 109

Today's Topics:

Re: protecting mac files via locking (Mac)
Locking Disinfectant (Mac)
Source for M-disk (PC)
Inside the Whale-Virus (PC)
Re: Hypercard Antiviral Script? (Mac)
Re: Can such a virus be written .... (PC)
Re: Can such a virus be written .... (PC)
doom2:reply (PC)
Virus checking for Sun4 (UNIX)
Self-Modifying SETVER.EXE (PC)
Product Review (PC Plus Mag) (PC)
Re: Can such a virus be written .... (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Mon, 24 Jun 91 09:16:00 -0400
>From:    John Chapman <[e-mail]>
Subject: Re: protecting mac files via locking (Mac)

[e-mail] (Lee Ratzan) writes:
> Aplication locking on a Macintosh prevents a file from accidentally
> being destroyed (trashed) and to some extent from being altered.
> A user wants to know if locking Disinfectant on a hard disk will
> prevent it from being itself infected from a virus emanating
> from an infected floppy.
>
> The issue is whether we can trust a resident locked copy of
> Disinfectant to remain clean even if the hard disk on which it resides
> becomes infected.

  From what I understand, Disinfectant checks itself first thing when
it is launched.  If it has been altered in ANY way, it supposedly
renames itself to something like 'Trash Me' and quits immediately.  I
think the check it performs on itself is a little more complex than
just simple checksumming, but I am not sure.  Anyway, the theory is
that even if something were able to infect Disinfectant, it would not
allow itself to be run.
  (For those interested, I think this is also why you cannot alter the
MultiFinder partition size - it is somehow 'hard-coded' into
Disinfectant such that changing it in the Finder Get Info box doesn't
work).

  If you are particularly concerned, run the Disinfectant INIT on all
boot volumes.  This should prevent the infection of any program (not
just Disinfectant) from any known virus.  The INIT is unobtrusive,
VERY small (read 5K) and is very effective against anything that's
been found.  If you want more complete protection, I would suggest
trying GateKeeper (freeware) or the commercial packages SAM, Rival, or
Virex.  From what I have seen, all are excellent at blocking all known
virus, but their main strength is their ability to catch & block new,
unidentified viruses.  Unfortunately, this means they are far more
picky and sensitive than the Disinfectant INIT and may cause conflicts
with (a few) software packages and INITs.

  By the way, the current version of Disinfectant is 2.4 and may be
found on most good FTP archives (eg. sumex-aim.stanford.edu) as well
as several mail server archives.

> Lee Ratzan

- - John T. Chapman            [e-mail]
                    [e-mail]

Disclaimer:  These opinions are my own and do not necessarily reflect
        those of the University or of the manufacturers of
        the products mentioned above.

------------------------------

Date:    Mon, 24 Jun 91 09:15:49 -0400
>From:    Joe McMahon <[e-mail]>
Subject: Locking Disinfectant (Mac)

On Thu, 20 Jun 91, Lee Ratzan asked:
>A user wants to know if locking Disinfectant on a hard disk will
>prevent it from being itself infected from a virus emanating
>from an infected floppy.

No, but it's not necessary to do that anyway. See below.

>The issue is whether we can trust a resident locked copy of
>Disinfectant to remain clean even if the hard disk on which it resides
>becomes infected.

Yes, you can. Disinfectant has two methods of dealing with attempted
viral attacks on itself. First, its resource map is locked, meaning
that Disinfectant's resources can't be diddled with by unsophisticated
viruses; several of the older viruses are smart enough to unlock the
file it it is locked, but are not smart enough to deal with a locked
resource map.

Second, Disinfectant verifies itself at startup, and will refuse to
operate if it finds that it has been corrupted. I know of no virus
smart enough to break into it as yet.

>I have advocated that since we have no automatic virus checking
>software which is activated upon disk insertion or start up and since
>anyone can use the machine, the only way to be absolutely certain that
>integrity has not been compromised each morning is to boot up first
>with a trusted disk and run the trusted disk copy of Disinfectant
>against the hard disk files.

This is a reasonable procedure, especially since it really doesn't
take that long, and it is definitely safe. You might want to consider
augmenting Disinfectant with Gatekeeper and Gatekeeper Aid as well.
This would help in stopping WDEF/CDEF infections, as Gatekeeper Aid
checks disks as they are inserted.

 --- Joe M.

------------------------------

Date:    Mon, 24 Jun 91 13:59:17 +0100
>From:    ukpoit![e-mail]
Subject: Source for M-disk (PC)

Does anyone know of a source for M-disk, purchase, BBS, etc ?
    Thanks in advance
        Dave

------------------------------

Date:    Mon, 24 Jun 91 15:47:41 +0000
>From:    Martin Zejma <[e-mail]>
Subject: Inside the Whale-Virus (PC)

Hello virus-community |

About 2 month ago I got a (the) Whale-Virus from a friend, cause I've
been interested in dissasembling that famous monster ( just from the
size ).

After long nights of work I discovered almost all of the code, and it
seemed to be quite trivial , the unbelieveable mysterious actions I
expected to see didn't exist.

So the question is:
IS there ANY action triggered beside copying the MBR from the 1st
harddisk to a file appended with a warning message about the Fish #6
Virus and leaving some infected files destroyed ??? ( something like
the nice falling letters triggered by the Cascade Virus ?? )

                                          So long, Martin

PS.: if anybody wants more or less specific information about the Whale ,
     feel free to e-mail me.

+-----------------------------------------------------------------------+
| Martin Zejma                                8326442 @ AWIWUW11.BITNET |
|                                                                       |
| Wirtschaftsuniversitaet Wien  ---   Univ. of Economics Vienna/Austria |
+-----------------------------------------------------------------------+

------------------------------

Date:    Mon, 24 Jun 91 08:53:39 +0800
>From:    [e-mail]
Subject: Re: Hypercard Antiviral Script? (Mac)

Greetings,

>The code to scan a stack is essentially the same as the SearchScript
>code that y'all will find in your HOME stack, only you have to modify
>it to accept a file name (answer file...everyone remember now?...)
>anyway, after you do that, the search string is "set the script of".
>HOWEVER, it is possible that someone has the viri sitting in an XCMD
>or XFCN which they invoke, so you should also check the resources they
>have attached to their stack...so you see, it becomes a pain to simply
>scan the stack script because you also need to scan the resources to
>be effective.

I doubt that a general scanner for HyperTalk viruses can be created
due to the fact that all one has to do is encode the text of the
script to be inserted, and make decoding part of the infection
process.  Using this method along with "do"s you would never see a
plain text "set the script of" until it was too late.  It wil probably
be necessary to do as utilities such as Virex do, and enter specific
characteristics of each virus for which to search.

This is a tough area, every time someone here comes up with a way of
blocking this sort of thing someone else comes up with a way around
it.
                                     <->
Bruce Carter, Courseware Development Coordinator      [e-mail]
Boise State University, Boise, ID  83725              [e-mail]
(This message contains personal opinions only)        [phone]@phone

------------------------------

Date:    Mon, 24 Jun 91 11:11:06 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: Re: Can such a virus be written .... (PC)

[e-mail] (Steven van Aardt) writes:
>
>   Is it possible to write a PC virus which installs itself whenever
> you place an infected disk in the drive and do a DIR command ?

Boy, I was hoping this one would go away but was rong again.

1) No: You cannot contract a PC virus by doing a DIR, a virus must be executed.

2) Once you have executed a virus, it could take control of the PC and infect
   floppies in this manner as several people have pointed out, but you cannot
   BECOME infected in this manner.

                            Padgett

------------------------------

Date:    Mon, 24 Jun 91 11:11:20 -0400
>From:    [e-mail]
Subject: Re: Can such a virus be written .... (PC)

[e-mail] (Steven van Aardt)
writes:
>
>   Is it possible to write a PC virus which installs itself whenever
> you place an infected disk in the drive and do a DIR command ?

Yes. But on a PC this requires certain conditions, which mean it
probably wouldn't spread very far.

Mark Aitchison, Physics, University of Canterbury, New Zealand.

I would like to know just what these conditions are.  If you have an
clean, uninfected system with the normal system files, COMMAND.COM,
etc., I would think that it is impossible to infect system memory or
another disk by doing a directory listing on an infected diskette.
(Of course, if you don't have a clean system with unmodified system
files, anything can happen.)  At no time does COMMAND.COM transfer
program control to any executable code on a diskette when it does a
directory listing via the DIR command.  It looks at the diskette's
root directory, files, and all other areas of the diskette as pure
data.  There is no way for a virus to become activated and infect a
system if control is not passed to it at some point.  With regard to
the comment about the Stoned virus behaving this way, Stoned will
infect a diskette if you do a DIR on it from a system which has the
virus active in memory (as will most other memory-resident viruses).
The only way for it to become active is by booting a system from an
infected floppy or hard disk - it cannot become active if you do a DIR
on an infected diskette from a clean system.  And I would venture to
say that this holds true for viruses in general.


------------------------------

Date:    Mon, 24 Jun 91 08:26:53 -0700
>From:    [e-mail]
Subject: doom2:reply (PC)

Ross says:
=-=-=-=
>It would appear to me that VIRx 1.4 isn't cleaning up after itself.
>You guys just ran accross different bits of code because of different
>ares of RAM being used to store the search strings.

(Will I ever live this down?  One mistake and *bingo!* all over the
place.  Sigh.)
- -=-=-=-=-=
Ha. You mean I wasn't the first? :*>
You say:
- -=-=-=-="
Actually, the strings are trivially "encrypted" to prevent the image
out on disk from triggering who-knows-how-many other scanners out
there.
=-=-=-
On /DISK/, yes. But consider the amount of scanners, including MAcAffee that
look at RAM, as well. False trip city, as we have seen.
You say:
- -=-=-=
The answer is simple: whatever for?  The bad guys can certainly break
whatever coding scheme I use, thereby using the string list just as if
it were not encoded at all.
=-=-=
This misses the point altogether. My point was simply that without encryption
of one sort or another, even in RAM,  another package wil false trip. If you
think that people are going to depend on your package alone for protection,
this might not cause a problem. But a realitry check, ( facilitated by a quick
peek at the postings in here) will prove that doesn't happen.
You say:
- -=-=-
The signature a scanner uses is of no use to a bad guy unless he or
she already has the subject virus on hand, in any case.
=-=-=-
Of course not. My point in this case was the person doing the altering
to routre around your code being the original author. Moreover, we
have seen several varieties of a particular virus around, indicating
more than one person altered one person's code. This is commonplace.
(Can you say 'Stoned'? Sure. I knew you could.) Obviously, virus code
is being passed around, by writers of such code, like a wine bottle at
a garbage can fire. Getting the original code is therefore no problem.
You say:
- -=-=-=
>Encrypting the search strings in your code, therefore is always a good
>idea, as is cleaning up the mess your program makes in RAM. VIRx,
>apparently doesn't address these two points.

Wrong on both counts.  It is interesting, though, that about 20 beta
testers did not find that problem at all....

=-=-=
First point: How on earth is cleaning up RAM you've allocated with
your program before the program closes to be considered a BAD idea?
Diito a string encryption?

As for your beta testers not finding the problem, I suggest to you
that perhaps they missed a major problem.  WIthout being judgemental,
here, finding this problem after beta was complete would seem to call
into question the validity of certain of your test results.

Regards to you.
E
(Normal employer isolation disclaimers apply here... IE: They may or may not
agree with my thoughts in this matter)

------------------------------

Date:    Mon, 24 Jun 91 14:33:45 -0600
>From:    Xcaret Research <[e-mail]>
Subject: Virus checking for Sun4 (UNIX)

Can someone point me to information about virus checking for a Sun4
computer.  Is there ftp'able software or any good commercial software?

Thanks,
John

[Ed. While not specifically an anti-virus program, you might want to
start by looking at COPS.  It's available from comp.sources.unix and
by anonymous FTP on cert.sei.cmu.edu.]

------------------------------

Date:    24 Jun 91 23:38:48 -0400
>From:    Robert McClenon <[e-mail]>
Subject: Self-Modifying SETVER.EXE (PC)

     I just discovered after twenty minutes of unpleasantness that
SETVER.EXE, a feature of DOS 5.00, is implemented via SELF-MODIFYING
CODE.  The SETVER command is used to fake out applications which check
the version of DOS.  It seems that, rather than maintain a data file
separate from the .EXE file, Microsoft has chosen to implement
SETVER.EXE as a program which modifies itself whenever it is executed,
so as to change a table that is part of itself.

     This is very unfriendly behavior for users who try to maintain
any sort of discipline to control viruses, or any of various other
sorts of discipline.  Virex-PC gave me multiple alerts telling me that
SETVER was trying to alter SETVER.  Since the syntax of SETVER is a
little peculiar and complex, I at first assumed that I had entered the
command wrong and was doing something improper and that Virex-PC was
protecting me from a mistake.  It took me a while to realize that
SETVER was REALLY trying to MODIFY itself and that Virex-PC was trying
to protect me from a technically legitimate but undisciplined
operation.

     Is anyone from Microsoft on this distribution list?  Would they
care to explain why they did such an undisciplined thing?

          Robert McClenon
          Neither my employer nor anyone else paid me to say this.

------------------------------

Date:    Tue, 25 Jun 91 09:54:36 +0700
>From:    James Nash <[e-mail]>
Subject: Product Review (PC Plus Mag) (PC)

A well written article (for a change!) appears in the current issue of
UK magazine PC Plus, called "Immune Systems". It sets out to explain
viruses, offering concise understandable defintions of all those terms
you know and love (plus "Armoured Virus"!).

Anyway, the main body of Mark Hamilton's article is a review of 10
anti-viral software products. Nearly all of these are UK products,
half of which I've never heard of before. It gives a real lashing to
Defiant Systems' "Virus Hunter" and verbally assualts Visionsoft's
"Immunizer". That latter one comes last in all the tests!

The one he recommends is Jim Bates' (Bates Associates) "VIS Utilities"
(5 * rating). Also praised are RG Software's "VI-SPY" - 'best US package'
- - , Sophos' "Sweep" and S&S's "Dr. Solomon's".

Software not included in the review were Mcaffee and F-PROT to name a
few.

For scanning accuracy, Bates came top, Solomon and Sophos close;
    only Norton, Visionsoft, Defiant Systems and Virex-Pc (1.1a)
    came below 75%.
For scanning floppies (Speed), Bates came top, Central Point close,
    others struggling.
For scanning Hard Disks (Speed), Norton came top (just), followed by
    Defiant Systems, Solomons, Bates and Central Point (ITO).

If anyone wants more info, buy a copy of PC Plus or e-mail me
direct. Please don't clog up the list with "me too" messages :-)
- --
James Nash // Computing Services // Phone: x8644 // User ID: ccx020 (cck)
- -I spilt Spot Remover on my dog and now he's gone.
[e-mail]

------------------------------

Date:    25 Jun 91 10:12:24 +0000
>From:    [e-mail] (Fridrik Skulason)
Subject: Re: Can such a virus be written .... (PC)

>[e-mail] (Steven van Aardt) writes:
>  Is it possible to write a PC virus which installs itself whenever
>you place an infected disk in the drive and do a DIR command ?

Not only possible - many such viruses already exist.  They are either boot
sector infectors which intercept INT13 and infect a disk whenever it is read
from, or file infectors which intercept the FindFirst/FindNext functions -
the DIR and DIR-2 viruses are a prime example.

- -frisk

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 109]
******************************************
VIRUS-L Digest   Wednesday, 26 Jun 1991    Volume 4 : Issue 110

Today's Topics:

I'm not official!
McAfee on VSUM accuracy and Microcom (PC)
Re: protecting mac files via locking (Mac)
Self-Modifying SETVER.EXE (PC)
Re: Hypercard Antiviral Script? (Mac)
Re: Hypercard Antiviral Script? (Mac)
FPROT116.ZIP uploaded (PC)
Re: Can such a virus be written .... (PC)
Re: Can such a virus be written .... (PC)
Re: Can such a virus be written .... (PC)
Re: Can such a virus be written .... (PC)
Inside the Whale-Virus (PC)
Announcing McAfee VIRUSCAN Version 80 (PC)
Product Test - - Central Point Anti-Virus (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    24 Jun 91 14:55:48 -0400
>From:    "David.M.Chess" <[e-mail]>
Subject: I'm not official!

A couple of (excellant) informational posts by Rob Slade recently have
listed me and/or Bill Arnold as contacts for IBM's Anti-Virus Product.
This is just a note to clarify: I'm just a humble researcher, *not* an
official IBM contact of any kind.  You can't buy the product from me,
I'm not an Official Support Person, you shouldn't send me Purchase
Orders, etc.  This applies to Bill as well.  I'm happy to answer
questions about the product that come up on VIRUS-L when I have a
chance, of course.  But to actually buy the product, talk to an IBM
Rep (call your nearest IBM Branch Office; if they don't know about the
product, tell them to "look in the SECURE section of NATBOARD", or
give them my name), or look in the Electronic Software Delivery
section of IBMLINK (if you're an IBMLINK customer).  This all applies
to Bill as well (unless he posts otherwise, hehe).

Dave Chess
High Integrity Computing Lab
IBM Watson Research

------------------------------

Date:    Tue, 25 Jun 91 10:04:30 -0700
>From:    [e-mail] (McAfee Associates)
Subject: McAfee on VSUM accuracy and Microcom (PC)

The following message is forwarded from John McAfee:

     I regret that I haven't had much time to keep up with Virus-L
recently, especially since it is one of the more informative sources
of virus information.  Fortunately, Aryeh Goretsky, Morgan Schweers,
Fritz Schneider and others have been kind enough to digest the bulk of
the Virus-L information and forward to me bits and pieces that they
feel my feeble mind can manage.
           A couple of postings made recently by Terry Reeves Ross
Greenburg need a response.  Specifically:

>From:   [e-mail] (Terry N Reeves)
>Vsum still says no utility will remove joshi and that a low level
>format is required.....
>     Is there a utility Ms. Hoffman?  perhaps you just don't want to
>admit it because McAffe's can't?  (i have not tried McAfee but I
assume >she'd say if his did.)

The McAfee Clean-Up program has been able to cure the Joshi since the
Joshi first appeared more than ten months ago.  What is curious about
this message is that Terry has not tried our product, yet tacitly
assumes that it cannot perform a given function.  The reason he gives
for this assumption is that the VSUM author doesn't want to admit that
anyone could cure the Joshi because McAfee cannot.  Have we really
reached this level of acrimony within this industry?  Isn't it enough
that most of us are trying our best to thwart a growing number of
virus writers and an escalating infection incidence?  Is there that
much spare energy left to throw stones at people like Patricia
Hoffman?  If Patricia, who works harder at analyzing and reporting
viruses than anyone I know, is now a flame target, then what's left?
I have been aware that VSUM did not report a disinfector for Joshi
(even though Clean-Up had been disinfecting it for 8 releases of VSUM)
but so what?  Out of 500,000 bytes of fine reporting in VSUM, should I
be so insecure that I have to correct Patricia's document so the world
will know that the McAfee products disinfect yet another virus?  Is
there really time and energy for such trivia?

And the second posting:

>From:  Ross Greenburg
>One of the interesting things:  Microcom, the people who publish and
>market my code, is expressly forbidden from using McAfee products by
>the vendor itself.

This is news to the alleged vendor.  Since McAfee Associates is the
only vendor of the McAfee products I assume Ross means us.  We have
never refused to sell our products to anyone, and our policies will
not change.  It's a strange comment considering that 99.9% of all of
our users use our products without telling us or paying us anyway (one
of the side effects of shareware).  How would we ever know?

In any case, it's good to exercise my fingers again and communicate
with this growing body of concerned persons.  My best wishes to my
detractors (many), admirers (few) and lethargics (the silent majority)
alike.

- - - -
End of forwarded message.

While John is not regularly on the Internet, I will forward any replies
to him, however, it would probably be best to contact him directly via
telephone or fax at any of the numbers below.

Aryeh Goretsky
McAfee Associates Technical Support

------------------------------

Date:    Tue, 25 Jun 91 10:56:52 -0900
>From:    "Jo Knox - UAF Academic Computing" <[e-mail]>
Subject: Re: protecting mac files via locking (Mac)

On 21 Jun 91, [e-mail] (Michael Kerner) says:

> NO!  ABSOLUTELY NOT TRUE IN ANY WAY, SHAPE, OR FORM.  IT IS IMPOSSIBLE TO
> PROTECT A FILE BY LOCKING IT.  PERIOD.  ABSOLUTELY NOT.  IT DOESN'T HAPPEN.

Agreed.

> The only way to protect a file is to have it on a locked volume.

Depends upon how the volume is locked; the only true locking is hardware
write protection, available on floppies and some optical drives (I think).

> However, I have an "utility" which will
> overwrite any resource in any file, and that's all the more specific I am
> going to get about it because I don't want some amateur hack reading this
> to get any ideas.  Saying that it can be done is bad enough - it encourages
> the ones that don't know ... yet.  At any rate, file locking AND PROTECTING
> (via some sector editor) do not stop this "utility" from working - no, it's
> not ResEdit, but I haven't tried ResEdit, although I would assume that it
> won't work.

I don't think any hacker's going to be surprised at this information;
"File Locked", "File Busy", "File Protect" are just bits in the header
information of the file; there are lots of utilities which can modify
some or all of these file attribute bits---if Finder (just another
program to the Mac) can set these bits, it's evident that other
programs can, too, such as ResEdit, MacTools/ FileEdit, SUM Tools,
Fedit Plus, and DiskTop DA, to name just a few.
jo

------------------------------

Date:    Tue, 25 Jun 91 15:11:00 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: Self-Modifying SETVER.EXE (PC)

>From:    Robert McClenon <[e-mail]>
>     I just discovered after twenty minutes of unpleasantness that
>SETVER.EXE, a feature of DOS 5.00, is implemented via SELF-MODIFYING
>CODE.

Actually, this is much better than earlier (beta) verions in which
SETVER modified other things (even nastier).

Since I did not bother to install SETVER, this is not a problem for me
and have not yet run into an application/game/etc that requires its
use.  Though I have heard rumors of such programs.

Further, one one teaches SETVER which (shouldn't be many) programs
require DOS to report/act like a different version to work, SETVER
should not be changing unless a new non-conforming program is added.

Even so, the rate should not be a problem, & the user should know that
something "legal" was done.

For some time, my feeling has been that "intelligent" anti-viral
software should be able to recognize when a program is allowed to
write to itself (SETVER, LIST) or to a limited subset of other
programs (WSCHANGE - WORDSTAR) & notify the user but not make a fuss
about it. Now if SETVER tries to modify LIST, I would be concerned,
but not when it modifies itself when I ask it to.

To me, strict checksum coverage of 98% of my files is "good enough"
(quantum economics) that not much safety would be lost if the other 2%
were permitted LIMITED privilege with notification. Heck, the whole
concept of "privilege" receives only lip service (and much
obfustication) from DOS.

IMHO, it would seem that MicroSoft had a choice: let SETVER modify
system files (tried & rejected in beta), a separate data file
(possible but must always be able to find it), or itself. Given all
the variables, I think they probably made the most efficient (but not
necessarily the most popular to anti-virus program writers) decision.

                        Cooly,
                            Padgett

Might be some one else's opinion also but probably not my employer's.

------------------------------

Date:    Tue, 25 Jun 91 19:21:10 +0000
>From:    [e-mail]
Subject: Re: Hypercard Antiviral Script? (Mac)

>From: [e-mail] (Michael Kerner)
[stuff deleted]...
>and as long as LockMessages is set, and as long as one checks the
>script of stack xxx before opening it, it's essentially impossible to
>infect yourself by opening a stack - ASSUMING YOU CHECK THE SCRIPT OF
>THE STACK FIRST.

>The code to scan a stack is essentially the same as the SearchScript
>code that y'all will find in your HOME stack, only you have to modify
>it to accept a file name (answer file...everyone remember now?...)
>anyway, after you do that, the search string is "set the script of".
>HOWEVER, it is possible that someone has the viri sitting in an XCMD
>or XFCN which they invoke, so you should also check the resources they
>have attached to their stack...so you see, it becomes a pain to simply
>scan the stack script because you also need to scan the resources to
>be effective.

Mike, I appreciate what you're about & am not trying to engage in
one-upmanship but....  Don't forget that the script could be in any
object not just the stack script or an XCMD. Maybe SearchScript checks
all objects, I forget.  You won't find the string if it's
cocantenated--i.e.:

on openCard
  put "set the scr" & "ipt of ..." into virusVariable --search would miss this
  --other malicious code goes here
end openCard

Thanks for the advice about being able to check for a "set" within a
"send" I will really believe it after I test it, though.

If you'd like, I could send you the exact script which I believe can
bypass any HC "vaccine". Others need not ask, especially don't contact
my ID directly.

- --Eric

------------------------------

Date:    Wed, 26 Jun 91 01:01:06 +0000
>From:    [e-mail] (Michael Kerner)
Subject: Re: Hypercard Antiviral Script? (Mac)

I agree that with do's it becomes harder to insure that you catch a
virus, but I also think that it would be relatively easy to spawn out
(e.g. if the virus writer came up with his or her own encryption
method and used the stack script with do's to unencrypt the scripts)
and check fields and so forth for the necessary SETs.  I hadn't
thought about your idea before, but it is clever and does cloud the
issue some more.  What can make it even harder is if the commands to
be DOne are in a file which is also encrypted, and the stack first
unencrypts the files then uses the code in the files and in the fields
to unencrypt the other scripts that must be run.  My biggest concern,
though, is that there will also be a resource lurking in a stack whose
name and type and contents, obviously, can be changed to disguise them
by the virus calling a code resource that it has attached to itself
and thus fooling everyone, including the GateKeeper-like module of
SAM.  Why some virus hack hasn't done this yet is beyond me.  The
virus could be coded to encrypt itself on some date or time parameter
and need the system date or some similar mechanism to untie itself,
thereby making detection pretty difficult at best.  The detection
program would then have to look for the decoding resource, which may
also be obscured by making it look like something else.

My head is spinning from all the possibilities.  I'm just glad I don't
have a PC and have to tolerate all their virus problems.  To think
this all started on a Mac.

Mike

------------------------------

Date:    Sun, 23 Jun 91 23:07:08 -0500
>From:    James Ford <[e-mail]>
Subject: FPROT116.ZIP uploaded (PC)

The file FPROT116.ZIP has been uploaded to risc.ua.edu (130.160.4.7)
in the directory pub/ibm-antivirus.

Please note (once again) that mibsrv.mib.eng.ua.edu will no longer be
available after June 24, 1991.  The archive has moved to RISC.UA.EDU.
Please send all problems/complaints/suggestions to [e-mail]
or [e-mail].
- ----------
You cannot antagonize and influence at the same time.
- ----------
James Ford -  [e-mail], [e-mail]
              The University of Alabama (in Tuscaloosa, Alabama)

------------------------------

Date:    Wed, 26 Jun 91 11:00:42 +0000
>From:    [e-mail] (Fridrik Skulason)
Subject: Re: Can such a virus be written .... (PC)

It seems I misunderstood a question which was posted here a while ago,
so please disregard my earlier reply....

>[e-mail] (Steven van Aardt) writes:
>  Is it possible to write a PC virus which installs itself whenever
>you place an infected disk in the drive and do a DIR command ?

I wrote:

>Not only possible - many such viruses already exist.  They are either boot
>sector infectors which intercept INT13 and infect a disk whenever it is read
>from, or file infectors which intercept the FindFirst/FindNext functions -
>the DIR and DIR-2 viruses are a prime example.

But, as I said, this was a misunderstanding - I thought the original
poster meant whether a resident virus could infect a diskette simply
when the user issued a 'DIR' command.  However, the question was
whether a virus-infected diskette could infect the system, when the
user issued a 'DIR' command.

The answer to that question is a definite NO - on a PC, that is - but
I am not sure if the same applies to the Amiga or the Mac - perhaps
somebody else can clarify that.

Sorry about any confusion caused by my earlier reply...

- -frisk

------------------------------

Date:    Wed, 26 Jun 91 11:19:00 +1200
>From:    "Mark Aitchison, U of Canty; Physics" <[e-mail]>
Subject: Re: Can such a virus be written .... (PC)

[e-mail] writes:
> [e-mail] (Steven van Aardt)
> writes:
>>
>>   Is it possible to write a PC virus which installs itself whenever
>> you place an infected disk in the drive and do a DIR command ?

I wrote...

> Yes. But on a PC this requires certain conditions, which mean it
> probably wouldn't spread very far.
>
> I would like to know just what these conditions are.

I'm not sure if I should broadcast the way in which a virus could do
this, but I suppose I could mention the conditions...

(1) Have ANSI.SYS (or similar) loaded,
(2) Possibly make assumptions about what the user will type next,
(3) Assume the user doesn't look too hard at the directory listing.

I would expect such a virus, if it can be written, to have a low
chance of spreading far. However, it is important to accept that
*possibly* a virus could spread on PC's this way.

Mark Aitchison.

------------------------------

Date:    Tue, 25 Jun 91 15:10:24 -0700
>From:    [e-mail] (Rob Slade)
Subject: Re: Can such a virus be written .... (PC)

[e-mail] (Doug Krause) writes:

> [e-mail] (Steven van Aardt) writes
> #
> #  Is it possible to write a PC virus which installs itself whenever
> #you place an infected disk in the drive and do a DIR command ?
>
> Doesn't STONED act that way?

Well, yes and no.

(Parenthetically here, let me state that it is hard to state with much
assurance "what 'Stoned' does", since it must be the most widely
"strained" viral program around today.  But anyway ...)

The Stoned virus usually will infect any disk that you "read" with a
DIR command.  But, in fact, it will infect just about any disk that it
does access, regardless of how it does it.

That said, the various strains show tremendous differences.  I have
one which will only infect disks in the A: drive, and another which
refuses to infect anything unless som{ odd conditions{are satisfied.
(I haven't figured them out compltely, but one sure way to infect a
di{k is to read it with PCTOOLS.)

{(Sorry for the line noise today.)

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Tue, 25 Jun 91 17:17:19 +0000
>From:    [e-mail] (...Jose)
Subject: Re: Can such a virus be written .... (PC)

[e-mail] (Fridrik Skulason) writes:
>>[e-mail] (Steven van Aardt) writes
:
>>  Is it possible to write a PC virus which installs itself whenever
>>you place an infected disk in the drive and do a DIR command ?
>
>Not only possible - many such viruses already exist.  They are either boot
>sector infectors which intercept INT13 and infect a disk whenever it is read
>from, or file infectors which intercept the FindFirst/FindNext functions -
>the DIR and DIR-2 viruses are a prime example.

    I'm not sure that this (very correct) answer actually responds
to the question.  If I'm not mistaken, the question is whether a virus on
a diskette can infect the system/hard drive simply by doing a DIR of the
infected diskette; ie. can simply reading the infected disk cause the virus
to be loaded into memory.  I can't see how.

    Mr. Skulason, I think, is referring to a virus already in memory
subverting the DIR command to place itself on a clean diskette.

    Have I interpretted everyone's statements correctly?

            ....Jose

- -----------------------------------------------------------------------------
".sig quotes are dippy"|Kenneth C. Moyle          [e-mail]
 - Kenneth C. Moyle    |Department of Biochemistry     [e-mail]
                       |McMaster University       ...!uunet!mnetor!maccs!kenm

------------------------------

Date:    26 Jun 91 14:40:21 -0400
>From:    "David.M.Chess" <[e-mail]>
Subject: Inside the Whale-Virus (PC)

No, I don't think anyone's ever found any evidence of any significant
"payload" inside the Whale.  It spent so much (primarily futile)
effort in being hard to analyze that it didn't have room for any
sophisticated payload (or even for correct operation, hehe!).  DC

------------------------------

Date:    Tue, 25 Jun 91 18:01:29 -0700
>From:    [e-mail] (McAfee Associates)
Subject: Announcing McAfee VIRUSCAN Version 80 (PC)

WHAT'S NEW

VIRUSCAN

     Versions 78 and 79 of VIRUSCAN were skipped because of two
trojan horse versions that appeared.  Version 80 of SCAN logically
follows V77.
     Version 80 adds several new features to VIRUSCAN:
     The first is that SCAN now checks inside of files compressed
with PKWare's PKLITE program for viruses.  Files infected before
compression will be reported as being infected internally.  Files
infected after compression will be reported as being infected
externally.
     When a subdirectory is scanned, SCAN will check subdirectories
below that subdirectory when the /SUB option is used.
     The extension .SWP has been added to the list of extensions
scanned by default.
     The /REPORT option now displays version number, options used,
date and time, and validation code results.
     Also, the capabilty to detect unknown boot sector viruses by
scanning for virus-like code has been added.  If a boot sector is
found that contains suspicious code, SCAN will report that the disk
contains a Unrecognized Boot Sector Virus.
     51 new viruses have been added.  Ones that were reported at
multiple sites are:
     The Telephonica virus -- a memory-resident multipartite
virus that infects the boot sectors of floppy disks, the hard disk
partition table, and .COM files.  The virus infects .COM files at
about 15 minute intervals, and keeps a counter of the number of
reboots that have occurred.  When 400 reboots have occurred, the
virus displays the message "VIRUS ANTITELEFONICA (BARCELONA)" and
formats the hard disk.  The virus has been reported at multiple
sites in Barcelona, Spain and in England.
     The Loa Duong virus -- a memory-resident floppy disk and hard
disk boot sector infector.  It is named after a Laotian funeral
dirge that it plays after every 128 disk accesses.
     The Michelangelo -- a floppy disk boot sector and hard disk
partition table infector based on the Stoned virus.  On March 6,
Michelangelo's birthdate, it formats the hard disk of infected
PC's.
     The Tequila virus -- sent to us from the United Kingdom but
originates in Switzerland.  It is a memory-resident multipartite
virus uses stealth techniques and attaches to the boot sector of
floppies, partition table of hard disks, and .EXE files.  It
contains messages saying "Welcome to T.TEQUILA's latest
production.", "Loving thoughts to L.I.N.D.A", and "BEER and TEQUILA
forever !"


CLEAN-UP

     The Empire, Form, Loa Duong, Michaelangelo, Nomenclature,
Tequila and V-801 viruses have been added to the list of viruses
that can be successfully removed.


VSHIELD

     Version 80 of VSHIELD adds a command to ignore program loads
off of specified drives.  When the /IGNORE option is activated, the
user can specify from which drives VSHIELD will NOT monitor program
loads.  Also, the capabilty to detect unknown boot sector viruses
by scanning for virus-like code has been added.  If a diskette boot
sector contains suspicious code and a re-boot request is attempted
from the diskette, VSHIELD will disallow the re-boot and will
report that the disk contains a Unrecognized Boot Sector Virus.


NETSCAN

     Version 80 of NETSCAN adds 51 new viruses.


VCOPY

     VCOPY Version 80 hasn't been released yet, but should follow
in a couple of days, as usual.


THE NUMBER OF VIRUSES
     Version 80 adds 51 computer viruses, bringing the number of
strains to 293, or, counting variants, 714.


Aryeh Goretsky
McAfee Associates Technical Support

------------------------------

Date:    Tue, 25 Jun 91 08:02:40 -0600
>From:    Chris McDonald ASQNC-TWS-R-SO <[e-mail]>
Subject: Product Test - - Central Point Anti-Virus (PC)

*******************************************************************************
                                                                          PT-36
                                       June 1991
*******************************************************************************


1.  Product Description:  Central Point Anti-Virus (CPAV) is a product to
detect, disinfect and prevent virus infections as well as protection against
the introduction of "unknown" and/or malicious code.

2.  Product Acquisition:  CPAV is available from Central Point Software, Inc.,
15220 NEW Greenbrier Pkwy., Suite 200, Beaverton, OR 97006.  A marketing
number, current as of 6 Jun 91, is 1-800-445-4064.  The retail price of the
product is $129.00.  Site licenses are available.

3.  Product Testers:  Don Rhodes, Information Systems Management Specialist,
Information Systems Command, White Sands Missile Range, NM 88002-5506, DSN:
258-8174, DDN:  [e-mail]; Chris Mc Donald, Computer Systems
Analyst, Information Systems Command, White Sands Missile Range, NM 88002-5506,
DSN:  258-4176, DDN:  [e-mail] or cmcdonald@wsmr-simtel20.
army.mil.

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 110]
******************************************
VIRUS-L Digest   Thursday, 27 Jun 1991    Volume 4 : Issue 111

Today's Topics:

Correction to Volume 4 Issue 110
What info is avilable on viruses? (PC)
Why Patricia Hoffman's virus summary is not on SIMTEL20 (PC)
Re: Can such a virus be written .... (PC)
re: doom2:reply (PC)
Can such a virus be written .... (PC)
re: McAfee on VSUM accuracy and Microcom (PC)
VIRx Version 1.5 Released (PC)
Re: protecting mac files via locking (Mac)
Re: Virus checking for Sun4 (UNIX)
Re: Can such a virus be written .... (PC)
Re: McAfee on VSUM accuracy and Microcom (PC)
Re: Virus protection: what to use.

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Wed, 26 Jun 91 15:25:57 -0400
>From:    Kenneth R. van Wyk <[e-mail]>
Subject: Correction to Volume 4 Issue 110

In V4I110, I posted the first couple sections of a product review on
Central Point Anti-Virus by Chris McDonald, but forgot to add a note
saying that the rest of the review (and Chris's other reviews) is
available by anonymous FTP on cert.sei.cmu.edu (IP number
128.237.253.5) in the pub/virus-l/docs/reviews directory.

Sorry,

Ken

------------------------------

Date:    Wed, 26 Jun 91 16:09:13 -0400
>From:    Jean-Serge Gagnon <[e-mail]>
Subject: What info is avilable on viruses? (PC)

Does anyone have a list of different virusus and their know effects on
the computers that they infect? And where can I get the latest version
of SCAN?

I'm asking because I'm new to virusus. I've been in computers a while,
but never in such a virus prone environment like a University.

Any replies would be welcome as I have a very scarce knowledge about
this subject. I.e. I know about stoned and that's about it, I don't
even know what it does apart from saying "Your PC is now stoned!".

Thanks.

Jean-Serge Gagnon   Internet:  <[e-mail]>
                      Bitnet:  <[e-mail]>
Specialiste en Equipement Informatique
Hardware Maintenance Specialist
Universite d'Ottawa / University of Ottawa
[phone] ou/or 7183
Acknowledge-To: <[e-mail]>

------------------------------

Date:    Wed, 26 Jun 91 15:51:00 -0600
>From:    Keith Petersen <[e-mail]>
Subject: Why Patricia Hoffman's virus summary is not on SIMTEL20 (PC)

I have received many inquires as to why SIMTEL20 does not have VSUM,
Patricia Hoffman's virus summary list.

SIMTEL20 is prohibited by the author from carrying VSUM.  Patricia
Hoffman blamed us for a problem caused by someone who downloaded her
file from our collection.  Since her virus summary list is copyrighted
we must comply with her wishes, even though the file is available on
almost any BBS and many other FTP sites.

The file is available from risc.ua.edu [130.160.4.7] in the directory
pub/ibm-antivirus.

Keith
- --
Keith Petersen
Maintainer of the MSDOS, MISC and CP/M archives at SIMTEL20 [192.88.110.20]
Internet: [e-mail]    or     [e-mail]
Uucp: uunet!wsmr-simtel20.army.mil!w8sdz              BITNET: w8sdz@OAKLAND

------------------------------

Date:    Wed, 26 Jun 91 18:05:17
>From:    [e-mail]
Subject: Re: Can such a virus be written .... (PC)

>From:    [e-mail] (A. Padgett Peterson)
>
>[e-mail] (Steven van Aardt) writes:
>>
>>   Is it possible to write a PC virus which installs itself whenever
>> you place an infected disk in the drive and do a DIR command ?

>1) No: You cannot contract a PC virus by doing a DIR, a virus must be executed
.

There is at least one batch file running around that, when you "exec"
it, it turns into a virus.

If a machine is using ANSI.SYS, it is possible to rename files to
provide for reprogramming the keyboard.  An argument can be made that
causing the, say, F3 key to execute some program or some some batch
file due to it being reprogrammed could mean that doing a simple
directory could later *cause* a virus to be executed.

Ross

------------------------------

Date:    Wed, 26 Jun 91 18:20:33
>From:    [e-mail]
Subject: re: doom2:reply (PC)

>From:    [e-mail]
>
>>Actually, the strings are trivially "encrypted" to prevent the image
>>out on disk from triggering who-knows-how-many other scanners out
>>there.

>On /DISK/, yes. But consider the amount of scanners, including MAcAffee that
>look at RAM, as well. False trip city, as we have seen.

Sigh.  Look, I simply didn;t remove the strings from memory.  What's your
point?

>...[why should I bother to encrupt the strings except trivially?]...
>This misses the point altogether. My point was simply that without encryption
>of one sort or another, even in RAM,  another package wil false trip. If you
>think that people are going to depend on your package alone for protection,
>this might not cause a problem. But a realitry check, ( facilitated by a quick
>peek at the postings in here) will prove that doesn't happen.

No, I get the point: my income depends on it.  I had a bug.  It's fixed in
Version 1.5, released about ten minutes ago.  A reality check would show
that out of the thousands of people who run our code daily, about ten have
complained about the interaction due to a bug that is now fixed.

>My point in this case was the person doing the altering
>to routre around your code being the original author. Moreover, we
>have seen several varieties of a particular virus around, indicating
>more than one person altered one person's code. This is commonplace.
>(Can you say 'Stoned'? Sure. I knew you could.) Obviously, virus code
>is being passed around, by writers of such code, like a wine bottle at
>a garbage can fire. Getting the original code is therefore no problem.

No matter what string is used, and no matter what the encryption routine
for that string might be, it would be trivial to ascertain what that string
is -- and without having to break the encryption.  I know that your intentions
are most likely good, sir, but you really have not stopped to consider
all the issues before you post.  You may think you have the solution to a
non-problem, but your solution does nothing except add another area where
a bug can creep in without providing anything but a *potential* feel-good-
warm-fuzzy feeling.  It does nothing but provide me with extra work and
does not provide any benefit to the end user community.


>>>Encrypting the search strings in your code, therefore is always a good
>>>idea, as is cleaning up the mess your program makes in RAM. VIRx,
>>>apparently doesn't address these two points.

>>Wrong on both counts.  It is interesting, though, that about 20 beta
>>testers did not find that problem at all....

>First point: How on earth is cleaning up RAM you've allocated with
>your program before the program closes to be considered a BAD idea?
>Diito a string encryption?

Simply becasue somebody says that encrypting the strings is a good idea
does not make it a good idea.  And, except for a bug that occurred in
certain circumstances, the cleanup was typically done.


>As for your beta testers not finding the problem, I suggest to you
>that perhaps they missed a major problem.  WIthout being judgemental,
>here, finding this problem after beta was complete would seem to call
>into question the validity of certain of your test results.

Actually, it just showed that our beta testers did not run into that
problem (recall that the reports I mentioned above were limited in number).
This implies that they don't use one of our competitor's products. So what?
There are many people who opt not to use our competitor's products.  In
fact, I hope to make sure that hardly anyone uses any of my competitor's
products by providing better code than anybody else.

And, sometimes, a minor mistake is make and is blown way out of proportion.

Ross

------------------------------

Date:    Wed, 26 Jun 91 12:10:19 +0100
>From:    "Pete Lucas" <[e-mail]>
Subject: Can such a virus be written .... (PC)

Most DOS PCs do not implement a hardware 'media change' flag, so they
do not know that a diskette has been inserted until you try reading
from it.  (this is unlike an Apple Mac that has a 'media change' sense
on its diskette drive).
A virus doesnt 'know' that a new diskette has been inserted on a PC
until the virus has had a look at whats there. Of course the write-protect
notch/slide is 99.99% effective in my experience at preventing any
illicit writes; you would, of course, have write-protected any diskette
you put in the drive before doing the hypothetical DIR command, wouldnt
you?
(I do actually have a notchless diskette that on *some* drives can be
written to - the diskette jacket is semi-transparent and on drives
that use optical notch-sensing, enough light *sometimes* gets past to
make the thing writable....  oh confusion!)

          Pete Lucas [e-mail]    PJML%IA.NWL.AC.UK@UKACRL

------------------------------

Date:    Wed, 26 Jun 91 18:37:03
>From:    [e-mail]
Subject: re: McAfee on VSUM accuracy and Microcom (PC)

>From:    [e-mail] (McAfee Associates)
>
>>From:  Ross Greenburg
>>One of the interesting things:  Microcom, the people who publish and
>>market my code, is expressly forbidden from using McAfee products by
>>the vendor itself.

> We have
>never refused to sell our products to anyone, and our policies will
>not change.  It's a strange comment considering that 99.9% of all of
>our users use our products without telling us or paying us anyway (one
>of the side effects of shareware).  How would we ever know?

This is good news.  I was under the impression that Microcom attempted
to license a copy from you and was told that they may not use it
without a license and that a license would not be issued to Microcom
under any circumstances.

I am glad that the information given to me is false and that Microcom
is expressly being given permission to utilize this product from the
vendor.  I would presume there is a charge for such usage: what would
that charge be for *only* one computer to use your product? I'll be
sure to report that amount to the Microcom people I deal with.

Ross

------------------------------

Date:    Wed, 26 Jun 91 18:42:35
>From:    [e-mail]
Subject: VIRx Version 1.5 Released (PC)

I'm pleased to announce that version 1.5 of VIRx has been released,
today, for distribution.  VIRx is a freely distributable scanning
program -- there is *no* charge associated with it, although
copyrights *are* maintained by both Microcom and me.

You should be able to grab a copy off of SIMTEL-20 almost immediately.
Additionally, it is available on CIS and on my BBS at 212-889-6438.

===
                   What's New In VIRx Version 1.5
                   ==============================
Date: 6/26/91

   1.  VIRx 1.5 detects over 80 additional newly discovered viruses,
   bringing the total to almost 500.  This was accomplished without
   slowing down the scanner.

   2.  Wildcard string scanning is included for detecting viruses
   otherwise resistant to general scanner detection.

   3.  VIRx scans PKLite pre-compressed files internally about 10%
   faster than previous versions; probably not noticable except on
   slower machines.

Problems Corrected from v1.4:

   1.  Another rare problem with scanning certain Novell Network server
   volumes has been corrected.

   2.  The technique used to clean our scanning search strings out of
   memory has been changed. This change will prevent certain other
   anti-virus scanners from erroneously reporting an assortment of
   viruses active in the computer's memory immediately after a VIRx
   scan has completed.

   3.  Certain rare situations would result in VIRx scanning extremely
   slowly. This has been fixed.

------------------------------

Date:    Thu, 27 Jun 91 00:22:25 +0000
>From:    [e-mail] (Michael Kerner)
Subject: Re: protecting mac files via locking (Mac)

In regards to the "Well, you can override the bit settings" (sorry, I
forgot to copy the article in here), the point I was making was that
even beyond that, this little bugger (no it's not in the Sector Editor
group that was listed), will also overrun open resources - this is
something that I have not seen any other "utility" accomplish.  I know
it is possible to do, but I just haven't seen anybody do it.

Mike.
Mac Admin
WSOM CSG
CWRU
[e-mail]

------------------------------

Date:    27 Jun 91 11:13:40 +0000
>From:    [e-mail] (Tommy Pedersen)
Subject: Re: Virus checking for Sun4 (UNIX)

[e-mail] (Xcaret Research) writes:

>Can someone point me to information about virus checking for a Sun4
>computer.  Is there ftp'able software or any good commercial software?

I don't know if there are any ftp'able software but there is a
product called TCell which the company I work for manufactures.

***** BE AWARE!! Information about this commersial product follows... *****

TCell is more than an antivirus system, it detects any kinds of unexpected
changes to the file system. Thus it can also be used in software management
for example to keep control that software not is changed after it's release.
You can probably think of yet other use in your organization.

TCell can also be used as a virus detection tool for PC's using software
residuing on a unix server.

If you like more information, give me an email to [e-mail], call me
at [phone] in Sweden, fax me at [phone] or write to the address
below.

Tommy Pedersen
SECTRA AB
Teknikringen 2
S-583 30 LINKOPING

- --
/Tommy Pedersen
 ________________________________________________________________
|E-mail: [e-mail]        /\                            |
|S-mail: Tommy Pedersen          / /  Telephone: [phone]  |
|        Dept. of EE             | |        FAX: [phone]  |
|        Linkoping University    |.>                            |
|        S-581 83 Linkoping      |/                             |
|_______ SWEDEN ________________________________________________|

------------------------------

Date:    Thu, 27 Jun 91 12:40:19 +0000
>From:    [e-mail] (Thomas Nikolajsen)
Subject: Re: Can such a virus be written .... (PC)

[e-mail] (Fridrik Skulason) writes:

>>[e-mail] (Steven van Aardt) writes
:
>>  Is it possible to write a PC virus which installs itself whenever
>>you place an infected disk in the drive and do a DIR command ?

>The answer to that question is a definite NO - on a PC, that is - but
>I am not sure if the same applies to the Amiga or the Mac - perhaps
>somebody else can clarify that.

Amiga : yes it is possible, and done, I only know of one virus which does
        that, this one is called SADDAM.
        The "bug" that allows the method used by SADDAM is fixed in the (more
        or less released) new version of the operating system (AmigaDOS 2.0).
        I don't think it should be possible in AmigaDOS 2.0.

>- -frisk
thomas

------------------------------

Date:    Thu, 27 Jun 91 10:18:32 -0500
>From:    "Bonnie Scollon"<[e-mail]>
Subject: Re: McAfee on VSUM accuracy and Microcom (PC)

 John McAfee writes:

 >This is news to the alleged vendor.  Since McAfee Associates is the
 >only vendor of the McAfee products I assume Ross means us.  We have
 >never refused to sell our products to anyone, and our policies will
 >not change.  It's a strange comment considering that 99.9% of all of
 >our users use our products without telling us or paying us anyway (one
 >of the side effects of shareware).  How would we ever know?

This is not true. As the college virus tracker, I try to keep
up-to-date copies of most anti-viral products. Of course, I can obtain
copies of McAfee'ssoftware but when I try to pay the fee, I get back a
form letter saying they will not sell a single copy to a college -- we
must spend thousands to obtain a site license for ALL our PC's,
whether we would install the programs or not. If this is not a refusal
to sell, I would not know what else to call it.

We have a site license from another vendor which was considerably
cheaper.  Even that one is quite expensive considering that we don't
actually use the product on all the college computers. We are also
looking into a site license for F-PROT, since that is certainly the
cheapest site license around.

I did notice the inaccuracy in VSUM's Joshi listing. I, too, did not
want to nitpick a document that obviously requires great time and
effort to produce. I have tested several products with the Joshi virus
and all can now remove it. I have not been keeping up with my VIRUS-L
reading or I would have responded to that posting. CPAV, Vi-Spy and
F-PROT will all find and remove it. My copy of Virex-PC did not but
the dates on the files are over a year old, even though we purchased
from Egghead only 4 months ago. (I have never received any update
info). I do not remember if NAV removed it or not. I rarely use it any
more in tests since it performed poorly when first tried.

 Bonnie Scollon
 Oakland Community College
 (in Oakland County MICHIGAN, not California)

------------------------------

Date:    26 Jun 91 09:47:22 +0000
>From:    [e-mail] (McAfee Associates)
Subject: Re: Virus protection: what to use.

Summary: Reposted by Keith Petersen

[e-mail] (Avinash Chopde) writes:
>I was looking around on the garbo.uwasa.fi site and found it had
>plenty of virus scanners/fixer programs.
>Do I need to get hold of all of them, or are there one or two
>which should suffice ?
>
>And, I'm interested in hearing about any of your own procedures that you
>follow to prevent virus infections and perform virus cleanups.

Hello Mr. Chopde,

There are lots of anti-viral programs available now, both shareware
and commercial, so without trying to be too specific, here are some
things you may wish to look for:

1.    Type of virus detection offered: That is, upon what criteria
does the anti-viral program base its "decision" that a virus has been
found?  This is generally broken down into three categories: filters,
changer checkers, and scanners.

A filter is a program that installs itself as a TSR and monitors the
system for virus-like activity (i.e., attempting to format a hard
disk, write to a program file, and so forth).  Filters have the
advantage of being able to detect new viruses because they are not
looking for specific viruses, but rather virus-methods.  The
disadvantage is that they can be prone to false-alarms by programs
which may do virus-like activities for legitimate reasons (say an OS
or application update program that patches the executable code of the
original program); they also have to be periodically updated when new
virus-techniques appear that the program did not monitor; also they
may have to be configured to allow programs that may do virus-like
activities (say, a disk optimization program) to function--this is not
really a problem with individual (home) users, but if you're
responsible for several 100's of PC's, installation could be painful.

A change checker (and this is a category that includes checksum,
cyclic redundancy checks (CRC's), cryptographic checks, and so on) is
a program that computes a known value for a program file (or other
area of the system) and is then periodically run to compare the
program file against.  If the known value and the just-computed value
don't match, then the file has been modified and may be infected with
a virus or otherwise tampered with.  The advantages to change checkers
are that they will detect known and unknown viruses, like the filter,
because they are not checking for specific pieces of code, but rather
for changes to a computed value.  They're also good for spotting
tampering--more of a computer security-related concern then virus-
specific, but it is a function.  The disadvantages of this method are
that this only works if the change checker is installed on a
virus-free machine, otherwise the known values computed will reflect
the viral code attached to its host; also, it's been theorized that if
the method of change checking is known, a virus could be written to
add itself to files in such a way that a checksum identical to the
known (good) checksum is generated; the last problem I can think of
with change checkers is that if there is a "stealth" virus present (A
virus that installs itself as kind of a "file handler" in the OS) then
the virus will trap reads by the change checking program, remove the
viral code from the infected file, and then pass on to the CC program
a "clean" file.  This last one can be prevented by booting the
computer with a clean (virus-free) operating system and then running
the change checking program.

A scanner works by checking the system for pieces of code unique to
each virus.  The scanner reads the files (boot sector, partition
table, etc) of a disk and does a match against a database of bytes
that are segments of viral code unique to each virus.  When a match
occurs, a virus is reported.  This is effective for finding known
viruses, since a positive ID against the virus is made.  Of course, a
false alarm could also occur if a file had the same instructions in
it.  Scanners can also check for "generic" routines, like a series of
program instructions to format a disk, but these are not as reliable
as the matching of viral code with its "fingerprint" of bytes because
a file may have use such a routine for legitimate purposes.
Disadvantages to this are that a scanner will only detect known
viruses and must be updated frequently, a "stealth" virus could hide
from the scanner, and possible false alarms.  And of course, as more
viruses are added, the scanner gets s l o w e r.


2.  Vendor Support: That is, what sort of assistance will the
manufacturer provide?

Anti-viral software (like any software tool, only more so <GRIN>)
generally requires more assistance then other forms of software, or
perhaps I should say, more assistance of a specialized nature.
Removing a virus can be somewhat tricky because a long set of steps
have to be precisely followed to remove a virus AND prevent
re-infection.  And of course, there is the matter of any data on
infected media that may have been corrupted in some way.  So,
knowledge (and it's accompanying twin, experience) are a factor.  What
sort of assistance does the vendor provide?  Does the vendor have a
telephone number, a fax, a BBS, internet or online services address
that you can access?  Is the telephone number 24 hours toll free?  Or
limited hours and toll.  Is there a charge for assistance or is it
free?  If there is a charge, do you have a certain amount of free
assistance?  What about local reps?  Is support handled through the
head office which may be in another country, or are there
manufacturer's reps or a branch office in your state (province,
district) or country?

Another factor is currency (yes, money too, but more about that next),
by which I mean how current is the program?  Does it need to regularly
updated?  Does an update file need to be added, or does the package
have to be completely reinstalled each time?  How are updates made
available, and for how long?  Can they be downloaded or mailed or
faxed to you?  Are they free or do you have to pay for them?  Do you
get a certain amount of free updates?  If so, how is this handled?  If
there is a cost for updates, how much is it?

Is the software purchased (or licensed) for life or for a certain
amount of time?  If for a limited time, then how long?  What happens
when the license period runs out?

And how much does it all cost?  And referrals.  Does the manufacturer
have satisfied customers whom you can ask about product?

Well, sorry for making such a long post, but I did want to address as
many issues as I could think of off the top of my head.  I hope this
gives you some factors to consider.

DISCLAIMER: Yes, I am an employee of McAfee Associates, makers othe
VIRUSCAN and CLEAN-UP anti-viral programs.  However, I have tried to
make this as objective as possible, without mention of anyone's
products, goods, or services.

Aryeh Goretsky
- --
McAfee Associates     | Voice [phone]    | [e-mail]
4423 Cheeney Street     | FAX   [phone]    | (Aryeh Goretsky)
Santa Clara, California     | BBS   [phone]    |
95054-0253  USA         | v.32  [phone]    | [e-mail]
ViruScan/CleanUp/VShield | HST   [phone] | (Morgan Schweers)

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 111]
******************************************
VIRUS-L Digest   Friday, 28 Jun 1991    Volume 4 : Issue 112

Today's Topics:

Re: Can such a virus be written .... (PC)
Re: VSUM accuracy and Microcom (PC)
Version 80 VALIDATE Results (PC)
Ross-bashing
Encrypted strings
Re: Can such a virus be written ... (PC)
doom2:reply (PC)
Self-Modifying SETVER.EXE (PC)
Re: Can such a virus be written .... (PC)
MacAfee Products (PC)
Trojan horses in data files
Interesting action with MACs (Mac)
VIRUSSCAN 80 (PC)
Virusafe 4.02 (PC)
North American Distributor of Virus Bulletin newsletter

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Thu, 27 Jun 91 13:41:35 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: Re: Can such a virus be written .... (PC)

Good grief - this question reminds ne of John Carpwenter's "The
Thing", it just will not die.

>>   Is it possible to write a PC virus which installs itself whenever
>> you place an infected disk in the drive and do a DIR command ?

NO, NEIN, NON, NEGATORY - you cannot write a virus to infect when an
uninfected PC does a DIR of an infected floppy disk (unlike the
Macintosh)

I don't care about batch files (which also execute, just
interpretedly), ANSI control sequences (which also execute), or 1-2-3
macros. In order to subvert the DIR command (not that difficult)
something MUST execute and a PC will mot execute ANYTHING without
being commanded to (boots result from a microcoded command designed
into the CPU - part of the reason for the 640k "barrier".

Of course, once resident, code can tell the processor to do anything
it is capable of doing via software, the operating system doesn't
care, and at any time. You want the PC to play "Yankee Doodle" at 5
pm? easy. You want all the letters to fall down in a pile on the
bottom of the screen every half hour ? trivial. But they all must
execute first and that takes human help either by leaving a floppy in
A when booting, or by executing an infected file (.COM, .EXE, .BAT,
.WK1, .SYS, .APP, or whatever).

If DIR could infect, it would be easy for an infected user to say
both/he/it she just put the disk in the drive to see what it was, but
no, they HAD to have tried to run "ASTROT*T" or "Kermit vs the Naked
Nazi Nymphs" or "1ON2" or that un-tested program with the
hand-lettered label in Arabic/Swahili/Kanjii.

While software commands could be hidden in a batch file with sequences
that would prevent reading by TYPE (but not from LIST or even
WordStar) and be passed as an unscannable uuencoded, packed,
compressed file, at some point some person had to tell it to execute
whether or not they knew thay were doing so. Only then can a virus (or
any other malicious software) infect a PC.

                        Padgett

   If this doesn't kill the subject, I'll have to use a lead pipe.

------------------------------

Date:    Thu, 27 Jun 91 13:36:08
>From:    [e-mail]
Subject: Re: VSUM accuracy and Microcom (PC)

>From:    "Bonnie Scollon"<[e-mail]>
>
>.... My copy of Virex-PC did not but
>the dates on the files are over a year old, even though we purchased
>from Egghead only 4 months ago. (I have never received any update
>info)....

Bonnie, please call 919-490-1277 and holler and scream at the folks at
Microcom?  I *know* that there have been many updates to the code in
last year, especially in the last quarter.  If you're a registered
user and you didn't receive a free update to Version 1.2, there is
something *very* wrong.

Version 2.0 has *finally* entered into final beta, and should be
available very shortly: for those who have purchased VIREX-PC
recently, send in your registration card and you'll get a free update
to Version 2.0.

We've disinfected Joshi for quite a while and Egghead selling outdated
code *really* burns my butt: please report the store number to
Microcom as soon as you can? Thanks!

Ross
 Author, Virex-PC, VIRx and FLU_SHOT+

------------------------------

Date:    Thu, 27 Jun 91 09:04:25 -0700
>From:    [e-mail] (McAfee Associates)
Subject: Version 80 VALIDATE Results (PC)

I've had a request from Europe to post the validation results for the
new release of SCAN (et al) because they do not receive the "Authentic
Files Verified" from the version of PKZIP distributed outside of North
America.

VALIDATE Results for Version 80 of SCAN/CLEAN/VSHIELD/NETSCAN

CLEAN-UP V80 (CLEAN.EXE)            S:119,999  D:06-24-91   M1: F8AE  M2: 05DD
NETSCAN V80 (NETSCAN.EXE)           S:87,437   D:06-24-91   M1: 705F  M2: 04F6
VIRUSCAN SCANV80 (SCAN.EXE)         S:87,437   D:06-24-91   M1: 58A9  M2: 0538
VSHIELD VSHLD80  (VSHIELD.EXE)      S:33,403   D:06-18-91   M1: 5607  M2: 0C19

VALIDATE Results for VALIDATE and VSHIELD1 (not changed since last release)
VALIDATE V03 (VALIDATE.COM) CRC Add S:6,495    D:10-31-89   M1: 4637  M2: 1214
VSHIELD1 0.2 (VSHIELD1.EXE)         S:11,281   D:02-14-91   M1: 6B40  M2: 103E

Aryeh Goretsky
McAfee Associates Technical Support

(Sorry for the delay, Paul!)

------------------------------

Date:    Thu, 27 Jun 91 16:00:34 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: Ross-bashing

Allright, enough already. So there was a conflict between two SCAN
programs that caused a "false positive" when one was run immediately
following another.  This is nothing new to the anti-virus industry, a
few months ago two products much closer related than Vir-X and
whatever the other one was consistantly reported the "12-Tricks" when
run one after the other. Until recently when memory scanning became
de-rigeur, and thank goodness it did, no-one bothered to clean memory
following a scan.

Remember the Prodigy STAGE.DAT controversy a few months ago ? It all
started when someone scanned the disks before installing the *P*
upgrade and discovered a host of virus names and strings inside the
.DAT file. Why ? My thought is that *P* needed to create a contiguous
fixed-size file on disk and did it the simplest way possible: by just
creating a giant memory buffer (without putting anything in it) and
copying it to disk to create the STAGE.DAT file. Whatever happened to
be in memory at the time was just swept along. Since a scanner had
just been run that left all of the strings in memory, this became
STAGE.DAT.

Now clearing free memory is trivial, one easy way would be for a
scanner to clear memory before loading, but then if a virus was
present a) the system would probably crash and b) you would not get a
virus report.

I fully expect the next generation of anti-virus tools to be able to
disconnect a virus from memory when found (if it can identify it, it
should be able to remove it and at least determine if it is active or
not).

On the subject of encryption, I agree with Ross, a trivial one is
sufficient to avoid false positives at least until signatures reach a
significant portion of the number of ten-byte signatures - on the
close order of 10^24 - which should take a while. To keep them
encrypted at all times except when individually used would cause an
extreme preformance loss for something that is already slow.

Meanwhile, the real key piece of information seems to have been missed
- - why the signatures were still in memory. When the second scanner
loaded, it should have overwritten the RAM Ross was using therefore,
for this to happen, Ross's code, when expanded in memory, had to be
longer than the subsequent program.  (why there probably have not been
more "false positives" rather than any deliberate avoidance). I
suspect that the "virus" string found was near the end of the expanded
search string list and the list followed the executable code.

Consequently, there may be an easier way than wiping memory - in a
program you have a choice as to where buffers are placed. If the
decrypted strings were kept in a buffer area at the front of the
program and followed by the executable code that (hopefully) does not
match anyone else's viral signatures, any other scanner that follows
should overwrite all the strings before starting.

Since when loading "high" a quick way to lock up a machine is to use
expanding buffers beyond the file size, these concepts should also be
considered by any memory resident routine.
                Just some thoughts,

                        Padgett

             Somewhere west of Orlando

ps Life is a learning process, when one stops, so does the other. - app

------------------------------

Date:    Thu, 27 Jun 91 13:21:28 -0700
>From:    [e-mail]
Subject: Encrypted strings

hi, Ross;

- -=-=-=
>On /DISK/, yes. But consider the amount of scanners, including MAcAffee that
>look at RAM, as well. False trip city, as we have seen.

Sigh.  Look, I simply didn;t remove the strings from memory.  What's your
point?
=-=-=
Exactly this:False trips cause problems for both you and the person
whose machine if falsely diagnosed as being infected.  Such false
trips cost both of you income. A point which, given the release info
I've just gotten on v1.5 you tend to agree with. You say:
=-=-=

>As for your beta testers not finding the problem, I suggest to you
>that perhaps they missed a major problem.  WIthout being judgemental,
>here, finding this problem after beta was complete would seem to call
>into question the validity of certain of your test results.

Actually, it just showed that our beta testers did not run into that
problem (recall that the reports I mentioned above were limited in number).
This implies that they don't use one of our competitor's products. So what?
There are many people who opt not to use our competitor's products.
=-=-=-

The ` so what' is that many others /do/....

Allow me to explain that one of the things I do for a living is such
testing.  IMHO, interfacing with other, similar products , where
possible, (even if only for direct a/b comparison) is part of a
complete test.
 You say:
=-=-=

And, sometimes, a minor mistake is make and is blown way out of proportion.
- -=-=-=

Sorry, Ross, if you thought my posting was blowing your error out of
proportion, but I honestly don't see how. Recall, please, that this
thread started with a general post was directed at all of us for input
on a specific problem.

My intent was not to attack a particular program. (Indeed, the names
of the packages the author mentioned were one point I didn't even
consider.... ) but rather, my intent was a general answer.

Good hearing from you.

------------------------------

Date:    27 Jun 91 15:41:00 -0500
>From:    "William Walker C60223 x4570" <[e-mail]>
Subject: Re: Can such a virus be written ... (PC)

Steven van Aardt ([e-mail]) writes:

> Is it possible to write a PC virus which installs itself whenever
> you place an infected disk in the drive and do a DIR command ?

Lots of people replied:

> Yes.

But A. Padgett Peterson ([e-mail]) replies:

> No ... you cannot BECOME infected in this manner.

Padgett is right.  To infect a PC, viral code must be executed from
the medium on which it is stored.  The DIR command does not execute
any code from the disk or diskette it is viewing, but just displays
the information contained in the sectors of the requested directory or
subdirectory.  Therefore, if you do a DIR of an infected diskette on a
clean PC, there is no way to infect the PC.  Someone else has
mentioned the possibility of renaming a file to contain ANSI.SYS codes
for remapping the keyboard, but this would not be transparent to the
user, as the remaining information (date, time, and size) would be
shifted to the left.

Bill Walker ( [e-mail] ) |
OAO Corporation                        | "Non sequitur -- your facts are
Arnold Engineering Development Center  |  un-coordinated."
M.S. 120                               |           -- NOMAD
Arnold Air Force Base, TN  37389-9998  |

------------------------------

Date:    Thu, 27 Jun 91 11:52:28 -0700
>From:    [e-mail] (Rob Slade)
Subject: doom2:reply (PC)

[e-mail] writes:

> Ross says:
> - -=-=-
> The signature a scanner uses is of no use to a bad guy unless he or
> she already has the subject virus on hand, in any case.
> =-=-=-
> Of course not. My point in this case was the person doing the altering
> to routre around your code being the original author. Moreover, we
> have seen several varieties of a particular virus around, indicating

While this arguement has some validity, I would suggest that it only
serves to reinforce a point made before in this forum, and which I
very strongly emphasize in my seminars and consulting.

The "my scanner is better than your scanner, nyaah" school of
evaluation misses a vital point: any two scanners are better than
either alone.  Even though I feel that Ross's product is one of the
best on the market, and I use it myself for my own testing and
protection, I would hate to see the day when it became the only one
available.  As Ross has pointed out, no matter how well strings are
encrypted, eventually someone will break the code, and then it is a
trivial matter to write a virus that circumvents that package.
However, with a number of scanner packages on the market (and even I
don't have them all), the author of a virus can never know which
package his code will have to go up against.

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Thu, 27 Jun 91 11:59:14 -0700
>From:    [e-mail] (Rob Slade)
Subject: Self-Modifying SETVER.EXE (PC)

[e-mail] (Robert McClenon) writes:

>      This is very unfriendly behavior for users who try to maintain
> any sort of discipline to control viruses, or any of various other
> sorts of discipline.  Virex-PC gave me multiple alerts telling me that

Unfriendly and, unfortunately, all too common.  Buried in the
documentation for Mace Vaccine, which has a change detection
component, you will find a note that self modifying programs will
trigger false alarms, and that Mace Utilities itself makes such self
modifying programs ...

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Thu, 27 Jun 91 16:17:25 -0500
>From:    THE GAR <[e-mail]>
Subject: Re: Can such a virus be written .... (PC)

>From:    Doug Krause <[e-mail]>
>>
>[e-mail] (Steven van Aardt) writes:
>#
>#  Is it possible to write a PC virus which installs itself whenever
>#you place an infected disk in the drive and do a DIR command ?
>
>Doesn't STONED act that way?
>
>Douglas Krause                     One yuppie can ruin your whole day.

NO!  Stoned does NOT act that way.

At least if I am understanding the question properly.  If I am, then
the virus is impossible.

Let me make sure I understand.  We have booted from some drive, C, and
are now, after the COMMAND.COM from C has been loaded, doing a DIR on
some infected disk, A.  The question is, can the infected disk A,
infect C.

NO.  The code that is being executed is in RAM, not on drive A.  Without
executing any code from A, we cannot invoke a virus.

STONED works by executing the boot sector on the infected drive A, but
this can only happen at boot time, not by executing a DIR command.

Macintosh's CAN infect C from A in the above case, because inserting a
disk executes the DESKTOP program on that disk.  If the DESKTOP on A
is infected, getting a listing will give you the virus  (WDEF usually!)


 /++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\
!  Later        +   Systems Programmer                                 !
!  Gary Warner  +   Samford University Computer Services               !
!               +   II TIMOTHY 2:15                                    !
 \+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++/

------------------------------

Date:    Thu, 27 Jun 91 16:06:00 -0800
>From:    [e-mail]
Subject: MacAfee Products (PC)

We investigated the issue of a license agreement with MacAfee, and it
turns out that they will issue a "group" license limited to ten users
who would have the right to do a virus check of the various LANs and
all their stations.  In other words, ten lab managers would have
unlimited right to use the product once we pay a $1500 fee
(approximately). At the same time, we are allowed to distribute the
product as shareware for individual users.  My interpretation: I
cannot use the product, except on a single station like any other
individual user, since we did not pay for the license, but I can make
it available to others for their personal use, leaving the question of
payment to their conscience.  It also means that I do not "distribute"
the copy to individual users who happen to be the office secretaries
in the various departments.  On the other hand, I do not feel overly
pressured to use this product since F-Prot (we payed the suggested
fee) seems to work just fine.

[e-mail]

------------------------------

Date:    27 Jun 91 23:57:00 +1700
>From:    [e-mail]
Subject: Trojan horses in data files

Mac and PC applications that read structured data files might be
tricked into executing a trojan horse by an ill-formed input file.
Given garbage input, word processors, picture displayers, and
spreadsheets sometimes crash by executing an illegal instruction.  If
the bytes making up this instruction come from the data file, the data
file can act as a virus installer.

I don't know if a DIR A: command can be tricked in this way; proving
that it can't be, no matter what's on the floppy in drive A, would be
a hard job unless the code is thoroughly defensive.

I do not believe such a trojan horse data file exists today.
We should
- - change scanners to scan all files, not just code
- - identify applications that are vulnerable to this attack and
  suggest they be repaired or avoided

Tom Van Vleck           <[e-mail]>

------------------------------

Date:    Thu, 27 Jun 91 22:25:22 -0500
>From:    Thomas Lapp <[e-mail]>
Subject: Interesting action with MACs (Mac)

This came from a colleague at work who works with our PCs.  In a
followup message she sent to me today, she indicated that a technician
seems to think it is more a problem with some flakey hardware taking a
bunch of other pieces out, and that it was just coincidence that
System 7 was going in at the same time...

If anyone else has seen anything like this, I'd be real interested in
knowing more, and passing it back to Barbara.

                -tom

 From:   NAME: Barbara J. Miller
         FUNC: ISD-P&DD/IT&E
 To:     NAME: Thomas L. Lapp <LAPPTL AT ISCDCVM3>

 Thought you might be interested in hearing about a "potential
 virus".  It has not been declared a virus by anyone at this
 point, but I always like to expect the worst until it is
 determined.

 From:   NAME: Barbara J. Miller
         FUNC: ISD-P&DD/IT&E
 Date:   26-Jun-1991
 Posted-date: 26-Jun-1991
 Precedence: 1
 Subject: Virus Alert - Mac's S7
 To:     See Below

 Virus Alert:

 I just received word of a virus that was encountered during a Mac
 System 7 installation.  Both the keyboard and mouse DIED on three
 machines that just had System 7 installed on them.  The customer
 then attached a voltage meter to the ADB port of a fourth machine
 only to find a unusually high reading.  It appears the virus
 destroys chips on the mouse and keyboard.


 Suggestions:  Be cautious when installing S7.
               Be sure it is a CLEAN copy - directly from Apple or
                  from CD-ROM.


 Apple has been contacted.
                         - tom
- --
internet     : mvac23![e-mail]  or  [e-mail] (home)
             : [e-mail] (work)
uucp         : {ucbvax,mcvax,uunet}!udel!mvac23!thomas
Location     : Newark, DE, USA

------------------------------

Date:    Fri, 28 Jun 91 10:58:34 +0000
>From:    [e-mail] (Richard Clarkson)
Subject: VIRUSSCAN 80 (PC)

What ftp sites are VIRUS SCAN 80 available from?

Can you supply the addresses?

Thanks in advance

Richard Clarkson

[Ed. See Jim Wright's monthly VIRUS-L/comp.virus archive site
postings.  These are posted at the beginning of each month.  The most
recent one was V4I96 on 3 June 1991; it is available by anonymous FTP
on cert.sei.cmu.edu in pub/virus-l/archives/1991]

------------------------------

Date:    Fri, 28 Jun 91 08:17:33 -0400
>From:    [e-mail]
Subject: Virusafe 4.02 (PC)

Any product or beta test on Virusafe 4.02. I have used it for a while
and it proves to be very reliable.  They are in Florida on 520 west
hwy. 436 suite 1180-30Altamonte Springs Florida 32714.
Please, reply.
Tito

------------------------------

Date:    28 Jun 91 13:19:01 -0400
>From:    Ray Glath <[e-mail]>
Subject: North American Distributor of Virus Bulletin newsletter

RG Software Systems, Inc. is pleased to announce our appointment as
North American Distributor for the acclaimed "Virus Bulletin" monthly
newsletter, published in the U.K.

This 25+ page highly informative and unbiased publication (no
advertising) contains detailed analyses of viruses, anti-virus
product reviews, trend projections, and news events concerning
viruses. Anyone wishing to subscribe should contact:

        Virus Bulletin
        c/o RG Software Systems, Inc.
        6900 E. Camelback Road, #630                Tel. [phone]
        Scottsdale, AZ  85251                       FAX  [phone]

One Year subscription cost: $ 350.00.
Back issues (from as early as July 1989) are available for $ 35.00
each.  Virus Bulletin states the following policy due to its
editorial content:

"Copies will only be sent to bona fide professionals. We reserve the
right to request additional evidence concerning the subscriber's job
function. Copies will not be mailed to private addresses without
verification."

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 112]
******************************************
VIRUS-L Digest   Monday,  1 Jul 1991    Volume 4 : Issue 113

Today's Topics:

Software pricing
System 7 Keyboard Trouble (Mac)
Ross Bashing? Not at all...
My 2 cents (Mac)
Beta Testing / DS "bug" report. (PC)
Re: Software Upgradable BIOS (PC)
Words
Re: McAfee on VSUM accuracy and Microcom (PC)
So, you think you're pretty safe, eh? (general)
Two versions of SCANV80.ZIP? (PC)
Requirements for Virus Checkers (PC)
Self-Modifying SETVER.EXE (PC)
Re: Can such a virus be written ... (PC)
Re: Ross-bashing
Encrypted strings
doom2:reply (PC)
Disinfectant 2.5 (Mac)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Fri, 28 Jun 91 14:58:17 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: Software pricing

I think I've missed something somewhere. $30/year for a single user
Hypercard stack of virus information (a very good one though I liked
it better as a flat ASCII file), $350/year for a soft cover anti-viral
magazine, and people are b*tch*ng about $1500/2 years with unlimited
updates to license software for 10 technicians to service (one would
expect) 10,000 PCs ? $0.15/pc ? They even give telephone support! The
answer is simple: if you don't like the price, buy something else (or
nothing), there are plenty of alternatives.

Better yet, write your own software and support it yourself, that just
takes learning and effort.

Problem is not many people today seem to have heard of John Galt or
TANSTAAFL.

                        Bemusidly,

                                Padgett

------------------------------

Date:    Fri, 28 Jun 91 16:06:20 -0400
>From:    Joe McMahon <[e-mail]>
Subject: System 7 Keyboard Trouble (Mac)

In re the report of Mac hardware trouble discovered in conjunction
with System 7 installation:

I believe this is caused by somebody unplugging ADB devices and
plugging them back in again while the power's on. This can blow the
ADB chip.

As far as I know, there are no software-controllable voltages/currents
to chips anywhere in the machine (exclusive of predetermined control
signals).

I think this is merely a coincidence. Do other machines which use the
same hard disk develop the trouble? Do other machines develop this
trouble when a program from the damaged one is run on them? If neither
of these is true, you don't have a virus, you have a hardware failure.

 --- Joe M.

------------------------------

Date:    Fri, 28 Jun 91 13:21:05 -0700
>From:    [e-mail]
Subject: Ross Bashing? Not at all...

Hi, Padgett:


Remember the Prodigy STAGE.DAT controversy a few months ago ? It all
started when someone scanned the disks before installing the *P*
upgrade and discovered a host of virus names and strings inside the
.DAT file. Why ? My thought is that *P* needed to create a contiguous
fixed-size file on disk and did it the simplest way possible: by just
creating a giant memory buffer (without putting anything in it) and
copying it to disk to create the STAGE.DAT file. Whatever happened to
be in memory at the time was just swept along.

=-=-=

Right. But in this case, since the resulting data was to be writen to
disk it would have made sense to use CALLOC, as opposed to MALLOC as
they seem to have.  In *P*'s case, clearing the RAM /before/ use would
hgave been the way to go.  Matter of fact, there's still some question
to my mind why they didn't go this route. I can find no practical
objection to doing so. Given that they must have thought of this
point, I have to assume they had some reason other than trivial
perfomance increases for not wanting to clear out the RAM in question.

But, we digress... you are most correct when you mention that clearing
RAMbefore scanning would crash the system and/or not report.  Because
of this I'm not suggesting that pre-clearing the RAM for scanners and
such... I'm merely suggesting clearing the already allocated RAM,
/after/ the thing is done. You say:
- -=-=-
When the second scanner loaded, it should have overwritten the RAM Ross was
using......
=-=-=

Well, for the first time in recent memory I'm going to disagree with
you, Padgett, for two reasons: Ross' program may not be using the same
area of RAM as John's. Given the diversity of anti=viral programs out
there, who knows where a program is going to leave it's signitures?
Would you have anti-viral writers clear all of RAM before scanning to
accomidate other such writers?  Clearly, the best way to accomplish
compatibility and reliability is for each writer to clean up their own
'mess'. You suggest:
=-=-=-=

If the decrypted strings were kept in a buffer area at the front of
the program and followed by the executable code that (hopefully) does
not match anyone else's viral signatures, any other scanner that
follows should overwrite all the strings before starting.
- -=-=-=
Bad move. You're assuming that everyone will use the same buffer area.
As for the strings (you hope) not being the same, isn't this where we
started this merry-go-round? Obviously, they /are/ the same, in many
cases, and that's where this problem started.

My best regards to you.
E

------------------------------

Date:    Fri, 28 Jun 91 17:09:00 -0400
>From:    "Mark Nutter, Apple Support" <[e-mail]>
Subject: My 2 cents (Mac)

Regarding all the recent flap about "can a virus infect a PC just by doing a
DIR of a floppy?"---

Looks to me like the original rumor was inspired by an incomplete
understanding of how the WDEF virus works on the Mac.  Since I have
seen some references to the Mac "executing the Desktop file" etc., I
thought I would try and clarify how WDEF worked.  Hopefully, this will
help clear up matters for both Mac users (who have to deal with it)
and PC users (who don't, but might be interested anyway).

The Mac OS allows any file to have a resource "fork", which is
essentially a simple database of menus, icons, code, configuration
settings, etc., that is associated with the data.  All executable code
is stored as a resource, but not all resource files/forks necessarily
contain executable code.

In systems prior to System 7.0, the Finder maintains an invisible
resource file called "Desktop", which is not supposed to contain any
executable resources.  (Finder is the program that lets you launch
programs, copy files, look at disk directories, etc.)  What WDEF did
was to copy an executable resource into the Desktop file.  This
resource was a resource of type "WDEF" (hence the name of the virus).
WDEF resources are supposed to contain code for drawing customized
windows, but this resource contained a virus which installed itself
and then called the standard WDEF code to actually draw the window.
The loophole exploited by the virus was that whenever the Mac OS needs
a resource, it searches ALL open resource files, beginning with the
last resource file to be opened.

Step by step: 1) user inserts WDEF infected disk. 2) Finder opens the
disk's Desktop file [note: no infection yet]. 3) user double-clicks on
a disk or folder icon to open up a window, 4) Finder looks for a WDEF
resource to actually draw the window, starting with the most-recently
opened file, 5) since the infected Desktop was the most recently
opened resource file, Finder executes the viral WDEF resource instead
of the standard System resource.  Infection occurs in step 5.

Observations: as of System 7.0, Finder no longer keeps any resources
in its Desktop files, thus under System 7.0 and future systems, the
loophole exploited by WDEF will no longer exist.  Users of pre-7.0
systems can be protected against WDEF (and other viruses that exploit
this loophole) by obtaining a copy of the FREE anti-viral utility
GateKeeper Aid and/or the Disinfectant INIT (also free).  These
utilities are available by anonymous ftp from sumex-aim.stanford.edu
in the info-mac/virus directory.  Also, if by any chance you think you
have a Desktop-infecting virus and you haven't got GateKeeper or
Disinfectant handy, you can easily disinfect it yourself without any
special hardware or software: just reboot the Mac and hold down the
Command and Option keys.  This signals the Finder to erase the old
Desktop file and re-construct it from the contents of the disk.  You
will lose any Get Info comments you may have (does anybody really use
those?), but you will also eradicate any *DEF viruses that may be
lurking on the disk.  Holding down Command/Option also works while
inserting new floppy disk.

- -----------------------------------------------------------------------------
Mark Nutter                                                      MANUTTER@IUP
Apple Support Manager
Indiana University of Pennsylvania
G-4 Stright Hall, IUP
Indiana, PA 15705
"You can lead a horse to water, but you can't look in his mouth." - Archie B.
=============================================================================

------------------------------

Date:    Fri, 28 Jun 91 17:17:57 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: Beta Testing / DS "bug" report. (PC)

I am just wondering if anyone has ever really had the experience of doing
a full V&V (verification and validation) process on any software ? The
amount of testing required is mind boggling (back in 1980 on a military
program involving a 4 Mhz embedded computer that could address a whopping
32K, the estimate was that it would take the better part of a century to
test every possible combination).

Having just discovered an obscure anamoly in DISKSECURE, let's use this for
an example:

DISKSECURE replaces the MBR of a hard disk with code (horrors !). It is
designed as a "technology demonstrator" to go resident before DOS loads
and detect/prevent MBR and Boot Record infections while preventing bypass
via a floppy boot.

It has been out "in the real world" for about six months and I have received
two reports and one possible of a problem. It seems that in an XT with
a 32 MB RLL disk (i.e. ST-238) using a Western Digital WD1002A-27X (NOT a
WD1002-27X, only the "A" version reported) with the 62-000094-002 BIOS when
jumpered to "translate" mode (makes the 615 track, 26 sector per track RLL
drive look like a 940 track, 17 sector/track MFM drive), the controller writes
17 bytes of "something" to the MBR in a normally unused area.

The WD folks I have talked to think it might be related to the "translate"
mode (they promised to look into it and get back to me RSN) and I have not
been able to decipher the 160+K of assembly language SOURCER provided me
of the WD BIOS yet.

The real "hooker" is that I added code to version 0.95 to read back the MBR
after DS installs and validate itself. Problem is it passes. I asked the people
(both over 1000 miles from me) to turn off any cacheing and reduce the buffers
to 1 (minimum DOS will accept). It still passes. But on the next boot, the
seventeen bytes are changed and the validation DS does on itself when booted
fails. For joy.

The point I am trying to make is that these kinds of obscure problems are going
to crop up in any code. I am told that the demos of 123/W crashed
repeatedly, Windows UAEs are legion, and have lost track of the letter
revisions of most major wordprocessing software.

In the antiviral world, the general level of the code is so good that we get
hung up when two different scanners, both of which work perfectly well on
their own, disagree with each other. For me, I am very pleasently astounded
that there are not more conflicts, false positives, or false negatives
considering the incredible array of equipment and viruses out there - the
talent that goes into any of the products is just incredible - and they all
get updated at least quarterly. And somebody always finds fault. Publicly.

So sure, I try to prod the manufacturers into the "next generation" by pointing
out what can be done & sometimes get a bit abrasive when my instinct tells
me that a wrong path is being taken - I've seen too many quotes that management
can seize on to say "we don't need protection", but then it is difficult to
conduct a meaningful discussion by remote control and no-one has any free time
at conferences.

Now, in the best of all possible worlds, MicroSoft and Digital Research would
sponsor a week-long offsite for anti-viral researchers to get together once
a year in a think-tank atmosphere for brainstorming. And if you believe the
that will ever happen, I have this bridge up north......


                            Padgett

      Somewhere west of Orlando - Tourist capital of the world

------------------------------

Date:    28 Jun 91 20:00:38 +0000
>From:    [e-mail] (Johnathan Vail)
Subject: Re: Software Upgradable BIOS (PC)

   [e-mail] (Terry Ingoldsby) writes:

   > It is not even necessary to place it under hardware control, rather if
   > the hardware incorporates an interlock that requires a special,
   > possibly unique, code, then the viruses could bash at it forever
   > (almost) without success.
   >
   > For example if each machine thus manufactured were assigned a unique
   > value in EPROM (which could not be read by the CPU), say of length 64
   > bits, then the user could be queried, by the software upgrade program,
   > to enter the key.  If the key matched, the EAROM would be modified,
   > otherwise nothing would happen.


The answer to the problem is simply to have a portion of uncorruptable
boot code.  This would allow the same level of protection available
with rock bound BIOS today.

This can be implemented in normal EPROM or a reserved portion of the
flashrom.

jv <<-- "Always Mount a Scratch Monkey"

 _____
|     | Johnathan Vail | [e-mail]
|Tegra| [phone] | N1DXG@448.625-(WorldNet)
 -----  [e-mail] {...sun!sunne ..uunet}!tegra!vail

------------------------------

Date:    28 Jun 91 19:50:32 +0000
>From:    [e-mail] (Johnathan Vail)
Subject: Words

Many months ago there was a small thread about various terminology and
several people suggested that I compile a list.  Here is that list.
This is a first draft and comments and additions are welcome.

Email responses are encouraged to reduce group traffic and I will
summarize the changes.

Thanks, jv


Law of Stolen Flight: Only flame, and things with wings.
                      All the rest suffer stings.
 _____
|     | Johnathan Vail | [e-mail]
|Tegra| [phone] | N1DXG@448.625-(WorldNet)
 -----  [e-mail] {...sun!sunne ..uunet}!tegra!vail


________________

virus - a piece of code that is executed as part of another program
    and can replicate itself in other programs.  The analogy to real
    viruses is pertinent ("a core of nucleic acid, having the ability to
    reproduce only inside a living cell").  Most viruses on PCs really are
    viruses.

worm - a program that can replicate itself, usually over a network.  A
    worm is a complete program by itself unlike a virus which is part of
    another program.  Robert Morris's program, the Internet Worm, is an
    example of a worm although it has been mistakenly identified in the
    popular media as a virus.


trojan (horse) - This is some (usually nasty) code that is added to a
    harmless program.  This could include many viruses but is usually
    reserved to describing code that does not replicate itself.


time bomb - This is code or a program that checks the systems clock in
    order to trigger its active symptoms.  The popular legend of the time
    bomb is the programmer that installs one in his employer's computers
    to go off in case he is laid off or fired.


magic cookie - This is a usually benign feature added to a product by
    the programmer without official knowledge or consent.  One example of
    the is the 'xyzzy' command in Data General's AOS operating system.
    Another is the "RESIST THE DRAFT" message in an unused sector of Apple
    Logo.


back door - This is an undocumented feature added to a product which
    can allow those who know about it to gain access to things that are
    otherwise protected.  The original Tempest video game was supposed to
    have a key sequence that would allow the author of the firmware to get
    free games in an arcade.  Some military systems are rumored to have
    back doors in their software that prevents their being used against
    the countries that built them.


stealth virus - This is a type of virus that attempts to hide its
    existence.  A common way of doing this on IBM PCs is for the virus to
    hook itself into the BIOS or DOS and trap sector reads and writes that
    might reveal its existence.


mixed terms - Many of the above terms can apply to the same piece of
    code.  For example a virus can replicate itself but not "do its
    dirty work" until a certain time.  It could be said to contain a time
    bomb.

------------------------------

Date:    Sat, 29 Jun 91 01:27:44 +0000
>From:    [e-mail] (McAfee Associates)
Subject: Re: McAfee on VSUM accuracy and Microcom (PC)

[e-mail] (Bonnie Scollon) writes:
[stuff deleted]
>This is not true. As the college virus tracker, I try to keep
>up-to-date copies of most anti-viral products. Of course, I can obtainn
>copies of McAfee'ssoftware but when I try to pay the fee, I get back a
>form letter saying they will not sell a single copy to a college -- we
>must spend thousands to obtain a site license for ALL our PC's,
>whether we would install the programs or not. If this is not a refusal
>to sell, I would not know what else to call it.
[rest of message deleted]

Hello Bonnie,

McAfee Associates policy on licensing is based on the concept that the
software is owned by whoever paid for it.  If a home user registers
with payment made by a business then the order is returned along with
a note stating that businesses must license the software if they wish
to use it.

In order to accomodate the different requirements of businesses, we
have three kinds of licenses available.  Service Industry Licenses are
for technicians who will use the software on any number of systems.
This kind of licensed is based on the number of copies to be used by
the technicians.  The software must be removed from the machine after
use.Small Business Licenses are for businesses with less then fifty
PC's.  We have two types of SBL's: a license for VIRUSCAN, CLEAN-UP,
and VSHIELD for computers or workstations; and a license for NETSCAN
for a file server or servers.  This allows small businesses without a
network to cut costs and add NETSCAN when the time comes.  Finally, we
have the Site Licenses, which are for businesses with 100 PC's or more
and go in increments of 100.  For Site Licenses, the VIRUSCAN,
VSHIELD, CLEAN-UP, and NETSCAN programs can be purchased either
separately or together.  We're flexible on how a site is defined: it
does not necessarily have to be an address, but can be all the
computers in a world-wide department or for a division of a company,
and so forth.  We also have corporate licenses available that cover
all the computers a business owns plus any and all added during the
license, increment licenses by pro-rating the amount already paid, and
offer educational discounts.

If you would like to discuss your situation further, I would recommend
that you contact McAfee Associates directly at [phone] and ask
for the sales department.

It has been our policy to provide access to our software and technical
support for five days without charge, and, if necessary, extend this.

Aryeh Goretsky
McAfee Associates Technical Support
- -
McAfee Associates     | Voice [phone]    | [e-mail]
4423 Cheeney Street     | FAX   [phone]    | (Aryeh Goretsky)
Santa Clara, California     | BBS   [phone]    |
95054-0253  USA         | v.32  [phone]    | [e-mail]
ViruScan/CleanUp/VShield | HST   [phone] | (Morgan Schweers)

------------------------------

Date:    Sat, 29 Jun 91 17:53:17 -0700
>From:    [e-mail] (Rob Slade)
Subject: So, you think you're pretty safe, eh? (general)

Note in passing Bill Hancock's editorial in the "Digital Review" of June
17, 1991.  Bill describes his recent encounter with a virus (unnamed, but
apparently fairly new) in their computer lab.  Bill is no slouch; he is a
highly competent technical lecturer.  The machines are all protected with
an antivirus program (also unnamed, but it appears to be a resident
scanner, perhaps VSHIELD.)

The virus infected the diagnostics programs that he tried to fix the
problem with.  Seemingly, the first indication he had was when a word
processor stopped working.  (Again, unnamed, but the description seems
consistent with Word Perfect.)

The piece is a good description, and, while I could wish he had made some
more helpful points about the level of risks in various situations (eg.
letting your scanner get out of date), his checklist for recovery is
thorough, if a little overblown.


=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Sat, 29 Jun 91 17:54:42 -0700
>From:    [e-mail] (Rob Slade)
Subject: Two versions of SCANV80.ZIP? (PC)

I retrieved SCANV80.ZIP from the wuarchive.wustl.edu mirror of
SIMTEL20, but when I went to repost it on a local board found a
different version.  Both versions appear to be authentic, with some
minor differences in text files:

Deep Cove version:
Searching ZIP: SCANV80.ZIP
Length  Method   Size  Ratio   Date    Time   CRC-32  Attr  Name
- ------  ------   ----- -----   ----    ----   ------  ----  ----
 17598  Implode   6962  61%  06-24-91  16:20  ac0b595f --w  AGENTS.TXT
  4026  Implode   1961  52%  05-24-91  15:23  02f06c2c --w  README.1ST
  5576  Implode   2288  59%  06-24-91  05:30  325e105d --w  REGISTER.DOC
 87437  Implode  47087  47%  06-24-91  03:47  eece6261 --w  SCAN.EXE
 28786  Implode  10695  63%  06-24-91  21:27  931869b9 --w  SCANV80.DOC
  6495  Implode   1895  71%  10-31-89  16:16  0449b09d --w  VALIDATE.COM
  2844  Implode   1406  51%  02-14-91  14:25  aa330b57 --w  VALIDATE.DOC
 24639  Implode   6532  74%  06-24-91  04:08  ce521c6f --w  VIRLIST.TXT
- ------          ------  ---                                 -------
177401           78826  56%                                       8

SIMTEL version:
Searching ZIP: SCANV80.ZIP
Length  Method   Size  Ratio   Date    Time   CRC-32  Attr  Name
- ------  ------   ----- -----   ----    ----   ------  ----  ----
 17598  Implode   6962  61%  06-24-91  16:20  ac0b595f --w  AGENTS.TXT
  3952  Implode   1942  51%  06-25-91  10:16  8643da95 --w  README.1ST
  5600  Implode   2307  59%  06-25-91  10:29  8858f474 --w  REGISTER.DOC
 87437  Implode  47087  47%  06-24-91  03:47  eece6261 --w  SCAN.EXE
 28777  Implode  10695  63%  06-25-91  11:18  678dddbb --w  SCANV80.DOC
  6495  Implode   1895  71%  10-31-89  16:16  0449b09d --w  VALIDATE.COM
  2844  Implode   1406  51%  02-14-91  14:25  aa330b57 --w  VALIDATE.DOC
 24320  Implode   6494  74%  06-25-91  11:15  64c446d0 --w  VIRLIST.TXT
  9785  Implode   4205  58%  06-25-91  11:19  3a5d3c03 --w  NETSCN80.DOC
 25050  Implode   8650  66%  06-25-91  10:34  39dc87eb --w  VSHLD80.DOC
- ------          ------  ---                                 -------
211858           91643  57%                                      10

It seems the only differences are found in:
              README.1ST
              REGISTER.DOC
              SCANV80.DOC
              VIRLIST.TXT
with the addition of two files:
              NETSCN80.DOC
              VSHLD80.DOC

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    30 Jun 91 00:53:46 -0400
>From:    Robert McClenon <[e-mail]>
Subject: Requirements for Virus Checkers (PC)

     Ross Greenberg says:

> EVERYBODY: Never accept a problem with a piece of code: the
> vendor can't fix it if they don't know there is a problem.

     The second clause is true but sadly irrelevant.  I wish every
developer were as attentive as Ross is to complaints.  I wish every
vendor were as responsive as Ross and Microcom are.  For those reasons
the first clause is good advice in general but not worth fighting
over.

     Ross was responding to my mention of two programs which
required that I disable Virex-PC.  The first was a game which hogs
conventional memory.  My thanks to Ross for reducing the size of
his TSR.  The second was a fax program which has interrupt
conflicts with Virex-PC.  Don't ask me why this fax program takes
over multiple interrupts.  I don't know either, and consider its
use of multiple interrupts to be evidence of strange design.  Ross
suggests I contact technical support at Microcom.  I did.  But I
don't think there is a problem with Virex-PC.  I also tried
contacting the technical support people with the developer of the
fax program.  They didn't understand.  I might as well have been
talking to robots.  They told me that obviously I wasn't supposed
to run the two programs at once.  If I had bought the program as
commercial software I would have asked for my money back at this
point.  But I didn't.  It was included with my modem as a package
deal.  Sometimes unpriced software is worth what you paid for it.
(Sometimes it is worth less, sometimes more.)

     There always must be a way to disable resident software, even
if it is not the fault of the resident software.  I did it by
writing a .BAT file which creates a dummy file; AUTOEXEC.BAT checks
for it and if it finds it suppresses the load of Virex-PC.
Maybe my dog doesn't like a guest who never bathes and says mean
things to the dog.  As a result, the dog barks all the time.  The
dog is trying to warn me and is doing his job.  But if I have a
reason to have the guest in my house, I may have to put the dog in
the back yard.  It is not the fault of the dog but of the guest.
There must always be a way to disable resident software.


          Robert McClenon
          Neither my employer nor anyone else paid me to say this.

------------------------------

Date:    30 Jun 91 00:52:45 -0400
>From:    Robert McClenon <[e-mail]>
Subject: Self-Modifying SETVER.EXE (PC)

     Padgett's comments are well-taken.  I would rather that SETVER
modified itself than that it modified something else.

     I am willing to concede that perhaps the use of an
undisciplined coding technique such as self-modification is
understandable for a program such as SETVER which deals with
undisciplined situations.

     I would have appreciated a warning from SETVER that it was
modifying itself.  Given the length of the message it produces when
executed, another line saying "SETVER is about to rewrite itself"
would not have been too much to ask.  Actually, I would suggest
that any other program which modifies itself should notify the
user.  There are other reasons than anti-viral compatibility to
warn a user of self-modification, such as the need to take a new
backup.

          Robert McClenon
          Neither my employer nor anyone else paid me to say this.

------------------------------

Date:    Sun, 30 Jun 91 12:47:52 +0000
>From:    [e-mail] (Anders Ohlsson)
Subject: Re: Can such a virus be written ... (PC)

    Hello all!

Quite interresting subject. After reading the last few postings
on the subject, I decided to test it. Here's what I found out.

Not only is it possible to write such a virus. In fact, you could put
any virus on a diskette, hide the file containing it and then do a
little editing using Norton Utilities or whatever.

One of you mentioned that the sizes and dates would be shifted to the
left. True. But...

I edited the volume label, and this was (in my eyes) a little less
obvious since all you will see when you DIR the disk is:

        Volume in drive A is
        Volume Serial Number is 4711-4711
        Directory of  A:\

        README              49 91-06-30   13.58
                1 File(s)    1456640 bytes free

I sure wouldn't notice the missing volume label. Would you?

All you have to do is edit the said volume label, and as somebody
pointed out, make some assumptions on what the user is going to do
next...

I think that many (including me) would read the README file...

So, all you have to do is to redefine the "t"-key (as in type)!

The ANSI sequence would for example execute a hidden file on the disk
in A:.

The hidden executable file could then in turn do a few things.  I
haven't tried these, and I don't think that any of them are
impossible...

    1. Clear the volume label
    2. Erase whatever the ANSI sequence typed on the screen
    3. Redefine the "t" to mean "t"
    4. Install whatever virus you like

I tried a little more harmless thing. A batch file that prints out a
little message, and it works just fine.

    Your turn...
                    - Anders Ohlsson
                    - [e-mail]

------------------------------

Date:    Sun, 30 Jun 91 15:26:02 +0000
>From:    [e-mail] (Ken Forward)
Subject: Re: Ross-bashing

[e-mail] (A. Padgett Peterson) writes:
> Allright, enough already. So there was a conflict between two SCAN
> programs that caused a "false positive" when one was run immediately
> following another....

Eeek!  My apologies if I contributed to this thread by reporting a
Taiwan3 false positive. My intent certainly was not to flame Ross or
his VIRx product; in retrospect I should have made that perfectly
clear in my posting.

As I see it, posting re a false positive is informative; it could
perhaps save somebody some grief. Padgett, maybe somebody saw those
warnings and decided they didn't need to low-level format their hard
drive !  :-) :-)

With thanks to Ross, Padgett and the many others who make our
computing lives more secure,
- ---------------------------------------------------------------------------
     Kenneth Forward             |   "...the large print give'th, and
     MUN Dept of Physics         |    the small print take'th away..."
     [e-mail]    |                         -Tom Waits-
- ---------------------------------------------------------------------------

------------------------------

Date:    Sun, 30 Jun 91 14:57:11
>From:    [e-mail]
Subject: Encrypted strings

>From:    [e-mail]
>
>>Sigh.  Look, I simply didn;t remove the strings from memory.  What's your
>>point?

>Exactly this:False trips cause problems for both you and the person
>whose machine if falsely diagnosed as being infected.  Such false
>trips cost both of you income.

Nothing personal,Eric, but don't teach Grandpa how to suck eggs?

>Allow me to explain that one of the things I do for a living is such
>testing.  IMHO, interfacing with other, similar products , where
>possible, (even if only for direct a/b comparison) is part of a
>complete test.

In order for a second program to pick up on this a false positive,
machines had to be configured in a certain way, program had to be run
in a certain order, etc.  My beta testers did not.  It's a problem,
yes, but it's a problem that any professional developer of these
products realizes that he's gonna run into from time to time.  You
deal with as quickly as you can, you try not to have scanner du'jour,
and you spend more time dealing with lots of postings from detractors
who do not understand the problem as completely as, perhaps, we do.

>>And, sometimes, a minor mistake is make and is blown way out of proportion.

>Sorry, Ross, if you thought my posting was blowing your error out of
>proportion, but I honestly don't see how. Recall, please, that this
>thread started with a general post was directed at all of us for input
>on a specific problem.

We have already given the problem more verbiage than it deserves. The
problem was fixed in Version 1.5.  If you want to continue to discuss
problems with an outdated version, you are welcome to do so, but I'm
done with this topic.

Ross

- ---------------------------

>
>Date:    Thu, 27 Jun 91 11:52:28 -0700
>From:    [e-mail] (Rob Slade)
>Subject: doom2:reply (PC)


>The "my scanner is better than your scanner, nyaah" school of
>evaluation misses a vital point: any two scanners are better than
>either alone.  Even though I feel that Ross's product is one of the
>best on the market, and I use it myself for my own testing and
>protection, I would hate to see the day when it became the only one
>available.

Wisw choice!  Wouldn't want you using one of them inferior products! :-)

>  As Ross has pointed out, no matter how well strings are
>encrypted, eventually someone will break the code, and then it is a
>trivial matter to write a virus that circumvents that package.
>However, with a number of scanner packages on the market (and even I
>don't have them all), the author of a virus can never know which
>package his code will have to go up against.

As a point of fact:  I have heard of a program floating about that
will take a subject virus and a subject scanner and will determine
*exactly* what the search string being used by that scanner for that
particular virus is.  And that it does this without dis-asming the
scanner at all -- simply by running it and playing some games with
the subject virus.

I agree with Rob entirely: use more than one scanner.  Mine, of course!
And, somebody else's.   I like Frisk's, Jim Bates',and Ray Glath's myself.
(I like mine better! :-) )

Ross

------------------------------

Date:    Sun, 30 Jun 91 14:57:11
>From:    [e-mail]
Subject: doom2:reply (PC)

>From:    [e-mail] (Rob Slade)
>
>The "my scanner is better than your scanner, nyaah" school of
>evaluation misses a vital point: any two scanners are better than
>either alone.  Even though I feel that Ross's product is one of the
>best on the market, and I use it myself for my own testing and
>protection, I would hate to see the day when it became the only one
>available.

Wisw choice!  Wouldn't want you using one of them inferior products! :-)

>  As Ross has pointed out, no matter how well strings are
>encrypted, eventually someone will break the code, and then it is a
>trivial matter to write a virus that circumvents that package.
>However, with a number of scanner packages on the market (and even I
>don't have them all), the author of a virus can never know which
>package his code will have to go up against.

As a point of fact: I have heard of a program floating about that will
take a subject virus and a subject scanner and will determine
*exactly* what the search string being used by that scanner for that
particular virus is.  And that it does this without dis-asming the
scanner at all -- simply by running it and playing some games with the
subject virus.

I agree with Rob entirely: use more than one scanner.  Mine, of
course!  And, somebody else's.  I like Frisk's, Jim Bates',and Ray
Glath's myself.  (I like mine better! :-) )

Ross

------------------------------

Date:    Fri, 28 Jun 91 14:53:28 -0600
>From:    [e-mail] (John Norstad)
Subject: Disinfectant 2.5 (Mac)

Disinfectant 2.5
================

June 28, 1991

Disinfectant 2.5 is a new release of our free Macintosh anti-viral
utility.

Version 2.5 detects the new C strain of the ZUC virus, recently discovered
in Italy. See the section on the ZUC virus in the 2.5 online manual for
details.

Version 2.5 also recognizes the MDEF D virus. We do not believe that the D
strain of MDEF was ever released to the public. Disinfectant recognizes it
anyway, just in case it was inadvertently released. See the section on
MDEF in the 2.5 online manual for details.

Neither of these two viruses is malicious, and we have no reason to believe
that either of them is widespread.

It is no longer possible to support the old 64K ROMs or operating system
versions prior to 6.0 in Disinfectant. Beginning with version 2.5,
Disinfectant requires a Mac 512KE or later model and system 6.0 or later.
These restrictions are necessary because Apple's Macintosh Programmer's
Workshop, which we use to develop Disinfectant, no longer supports the old
ROMs or old systems.

Version 2.5 corrects an error which sometimes caused Disinfectant to crash
after printing the online manual, especially on HP DeskWriter printers.

The online manual contains a new section titled "System 7 Notes." This
section discusses important issues regarding viruses, Disinfectant, and
System 7. It also describes our plans for Disinfectant 3.0. This new
section is reproduced in full below.

Disinfectant 2.5 is available now via anonymous FTP from site
ftp.acns.nwu.edu [129.105.113.52].  It will also be available soon on
sumex-aim.stanford.edu, rascal.ics.utexas.edu, comp.binaries.mac,
America Online, CompuServe, GEnie, Delphi, BIX, MacNet, Calvacom,
AppleLink, and other popular sources of free and shareware software.

Macintosh users who do not have access to electronic sources of free and
shareware software may obtain a copy of Disinfectant by sending a self-
addressed stamped envelope and an 800K floppy disk to the author at the
address given below. People outside the US may send an international postal

reply coupon instead of US stamps (available from any post office). Please
use sturdy envelopes, preferably cardboard disk mailers.

People in Western Europe may obtain a copy of the latest version of
Disinfectant by sending a self-addressed disk mailer and an 800K floppy
disk to macclub benelux. Stamps are not required. The address is:

   macclub benelux
   Disinfectant Update
   Wirtzfeld Valley 140
   B-4761 Bullingen Belgium

System 7 Notes
==============

Disinfectant 2.5 works properly with Apple's new System 7, provided you
remember the following three special rules:

1. Leave the Disinfectant INIT in the System Folder proper. Do not move
the INIT to the new Extensions Folder.

2. If you try to repair an infected file, Disinfectant may tell you that
the file is busy and recommend that you "try again without MultiFinder."
However, you can't turn off MultiFinder in System 7. If this situation
occurs, restart your Mac using the 800K "Disk Tools" startup floppy that
comes with System 7 (or any other startup disk which contains an old
System 6 startup System with MultiFinder turned off). Then run
Disinfectant again.

3. There is one small problem with Disinfectant's custom get file dialog
with which you can select a folder to be scanned. Don't try to select
anything in the Desktop level in this dialog. Disinfectant may crash or
scan the wrong object.

We are working on a new version 3.0 of Disinfectant which will fix all
three of the problems mentioned above. Following are some other features
planned for Disinfectant 3.0.

Version 3.0 will take full advantage of the new facilities available in
System 7, including Balloon help, color icon families, anti-viral and
other Apple events, icon dropping in the Finder, and proper placement of
the Preferences file and the Disinfectant INIT file in the new Preferences
and Extensions folders respectively.

Version 3.0 will eliminate the restriction that the INIT must load last.
The INIT will be renamed "Disinfectant Extension."

Version 3.0 will include a new "Upgrade" command which, in the future,
will make it possible for people to download very small upgrade files
instead of entire new versions of the program.

The version 3.0 online manual will include a very thorough discussion of
all the issues regarding viruses and Disinfectant as they relate to
System 7.

We hope to release version 3.0 later this summer.

You should also be aware that System 7 is completely immune to the
"Desktop file" viruses (WDEF and CDEF.) These viruses never activate,
spread, or cause any damage under System 7. Both hard disks and floppy
disks are immune to these viruses under System 7. Since the Disinfectant
INIT detects and blocks viruses when they first try to attack your system,
and since the Desktop file viruses never attack under System 7, the
Disinfectant INIT will not detect them under System 7. The Disinfectant
application, however, will still detect and remove the Desktop file
viruses.

You should also be aware of a problem with System 7's new file sharing
feature. If you share a folder and permit write access to it by granting
the "make changes" privilege with the new "Sharing" command, it is possible

for files in the shared folder to become infected by a virus over the
network, even if you have the Disinfectant INIT installed on your Mac. The
INIT will, however, prevent the virus from spreading to your non-shared
folders. It will also completely block any attempt by the virus to execute
it's viral code on your Mac or cause any damage to your Mac.

We have always had the problem of viruses spreading over a network to files

in writable folders on dedicated AppleShare file servers. With System 7's
new file sharing, this has now also become a problem on personal Macs.

Virus infection over the network is only one of many serious security
problems with writable shared folders. Writable shared folders are
inherently insecure, and no kind of anti-viral or other security software
can prevent damage to their contents. To minimize these problems, we
recommend that you limit write access to your shared folders to only
trusted individuals. Never grant write access to guests (any user.) The
only way to eliminate the problems completely is to never grant the "make
changes" privilege to anyone except yourself.


John Norstad
Academic Computing and Network Services
Northwestern University
2129 Sheridan Road
Evanston, IL 60208 USA

Internet: [e-mail]
Bitnet: jln@nuacc
America Online: JNorstad
CompuServe: 76666,573
AppleLink: A0173

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 113]
******************************************
VIRUS-L Digest   Monday,  1 Jul 1991    Volume 4 : Issue 114

Today's Topics:

Introduction to the Anti-viral archives, listing of 01 July 1991

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

------------------------------------------------------------

Date:    Sun, 30 Jun 91 03:48:59 -1000
>From:    Jim Wright <[e-mail]>
Subject: Introduction to the Anti-viral archives, listing of 01 July 1991

Introduction to the Anti-viral archives, listing of 01 July 1991

This posting is the introduction to the "official" anti-viral archives
of VIRUS-L/comp.virus.  With the generous cooperation of many sites
throughout the world, we are attempting to make available to all
the most recent news and programs for dealing with the virus problem.
Currently we have sites for Amiga, Apple II, Atari ST, IBMPC, Macintosh
and Unix computers, as well as sites carrying research papers and
reports of general interest.

    You may notice that in this edition of the list, every section has
    been modified.  The Atari ST list has added atari.archive.umich.edu
    run by Jeff Weiner, and Steve Grimm's site has changed to
    twitterpater.eng.sun.com.  All lists were affected by the loss of
    the Heriot-Watt archive server run by Dave Ferbrache.  His archives
    contained approximately 150MB of information and programs related
    to viruses and security.  It was through mail with Dave that I was
    prompted to hold the vote for comp.virus and start the anti-viral
    archive site list.  I wish him well in his new job and look forward
    to when he can go back "on the air".

If you have general questions regarding the archives, you can send
them to this list or to me.  I'll do my best to help.  If you have a
submission for the archives, you can send it to me or to one of the
persons in charge of the relevant sites.

If you have any corrections to the lists, please let me know.

The files contained on the participating archive sites are provided freely
on an as-is basis.

To the best of our knowledge, all files contained in the archives are either
Public Domain, Freely Redistributable, or Shareware.  If you know of one
that is not, please drop us a line and let us know.  Reports of corrupt
files are also welcome.

PLEASE NOTE
The Managers of these systems, and the Maintainers of the archives, CAN NOT
and DO NOT guarantee any of these applications for any purpose.  All possible
precautions have been taken to assure you of a safe repository of useful
tools.

Jim Wright
[e-mail]                     JWRIGHT@UHCFHT


------------------------------

Date:    Sun, 30 Jun 91 03:49:28 -1000
>From:    Jim Wright <[e-mail]>
Subject: Archive access without anonymous ftp, last changed 30 June 1991

Archive access without anonymous ftp, last changed 30 June 1991

To get files from the anti-viral archives, you do not need access
to anonymous ftp.  (However, anonymous ftp is generally the preferred
method.)  Below is information on accessing the archive sites using
only email.

                           -=-

One way to get access to the archives is through the BITFTP server
at Princeton.  Send a message to the BITNET address is BITFTP@PUCC
with the body of the message containing the single word HELP.  This
should get you more information, and give you access to any archive
site on the Internet.  Due to excessive loads, this service has been
restricted to BITNET and EARN sites only.  UUCP sites need not apply.

                           -=-

Both the AppleII and the Atari ST archives have mail servers which
provide access to their archives.  You may receive automatic updates
of Macintosh anti-viral programs via email.  See the individual articles
on these sites.

                           -=-

You may also retrieve files from the SIMTEL-20 and the INFO-MAC
archives by using one of the many mail servers which maintain
a shadow archive of these sites.  Send the following message to one
of the listserv sites.

help

See the IBMPC and Macintosh articles for a complete list of servers.


------------------------------

Date:    Sun, 30 Jun 91 03:49:59 -1000
>From:    Jim Wright <[e-mail]>
Subject: Brief guide to files formats, last changed 30 June 1991

Brief guide to files formats, last changed 30 June 1991

 -- The most recent copy of the complete text may be anonymous ftp'd --
 -- from ux1.cso.uiuc.edu (128.174.5.59) in the directory doc/pcnet. --
 -- That file is maintained by David Lemson ([e-mail]).       --
 -- Please do not strip this note from this list when passing it on. --

ARC (.arc)
    This format is most popular on PCs.  Compresses and stores multiple
    files in a single archive.
    PC     - arc 6.00, pk361
    Mac    - ArcMac 1.3c
    Unix   - arc 5.21
    VM/CMS - arcutil
    Amiga  - Arc 0.23, PKAX
    VMS    - arcvms
    Apple2 - dearc
    Atari  - arc 5.21b, pkunarc
    OS/2   - arc2

BinHex (.hqx)
    A Macintosh format.  Converts a binary Mac file, including data and
    resource forks, into an archive of only printing ASCII characters.
    Note that BinHex4.0 will create and decode the ASCII hqx encoding used
    on Usenet, while BinHex5.0 will decode the ASCII hqx encoding but will
    create a non-ASCII binary file.
    PC     - xbin 2.3
    Mac    - BinHex4.0, BinHex5.0
    Unix   - mcvert
    VM/CMS - binhex

binscii ( )
    A favorite Apple2 archive format.
    Apple2 - binscii

Compactor (.cpt)
    A new Macintosh format.  Compresses and stores multiple files in
    a single archive.
    Mac    - Compactor1.21

compress (.Z)
    A Unix format.  Compresses a single file in an archive.
    PC     - u16, comprs16, comp430d
    Mac    - MacCompress3.2A
    Unix   - compress
    VM/CMS - compress
    Amiga  - compress
    VMS    - lzcomp
    Apple2 - compress
    Atari  - compress

LHarc (.lzh)
    This format originated on PCs, and is now popular on Amigas.  Compresses
    and stores multiple files in a single archive.
    PC     - lh113c
    Mac    - MacLHarc 0.41
    Unix   - lharc10
    Amiga  - LHarc
    Atari  - lharc113

LHWarp (.lzw)
    This is an Amiga format.  Compresses and stores an entire floppy in a
    single archive.  Better compression than plain Warp.
    Amiga  - Lhwarp

LU (.lbr)
    This is an old format that originated with CP/M.  It is virtually
    non-existent now.  Collects multiple files into a single archive
    with no compression.
    PC     - lue220
    Mac    - ArcMac 1.3c
    Unix   - lar
    VM/CMS - arcutil
    VMS    - vmssweep

nupack ( )
    A favorite Apple2 archive format.
    Apple2 - nupack

PackIt (.pit)
    An old Macintosh format.  Compresses and stores multiple files in a
    single archive.
    PC     - UnPackIt
    Mac    - PackIt3.1.3
    Unix   - unpit

PAK (.pak)
    An old PC format.  Compresses and stores multiple files in a
    single archive.  Also the name of an Amiga format which produces
    self-extracting archives.  Also the name of a new PC format.
    PC     - pak250
    Unix   - arc 5.21
    Amiga  - PAK 1.0

shell archive (.shar, .sh)
    A Unix format.  Stores multiple files in a single archive without
    compression.
    PC     - unshar
    Mac    - UnShar2.0
    Unix   - sh, unshar
    Amiga  - UnShar
    Apple2 - unshar
    Atari  - shar

Squeeze (._Q_)
    An old PC (CP/M?) format.  Compresses and stores multiple files in a
    single archive.
    PC     - sqpc131
    VM/CMS - arcutil
    Amiga  - Sq.Usq
    VMS    - vmsusq
    Atari  - ezsqueeze

StuffIt (.sit)
    A Macintosh format.  Compresses and stores multiple files in a
    single archive.
    PC     - mactopc
    Mac    - StuffIt 1.6
    Unix   - unsit
    Amiga  - unsit

tape archive (.tar)
    A Unix format.  Stores multiple files in a single archive without
    compression.
    PC     - tar, tarread, pax, pdtar
    Mac    - UnTar2.0
    Unix   - tar
    Amiga  - TarSplit, pax
    VMS    - vmstar
    Atari  - sttar

uuencode (.uu, .uue)
    A Unix format.  Converts a binary file into an archive of only
    printing ASCII characters suitable for mailing.
    PC     - uuxref20
    Mac    - UMCP-Tools1.0
    Unix   - uuencode, uudecode
    VM/CMS - arcutil
    Amiga  - uuencode, uudecode
    VMS    - uudecode2.
    Apple2 - uu.en.decode

Warp (.wrp)
    This is an Amiga format.  Compresses and stores an entire floppy in a
    single archive.
    Amiga  - WarpUtil

xxencode (.xx, .xxe)
    A Unix format.  Converts a binary file into an archive of only
    printing ASCII characters suitable for mailing.  Solves many of
    the problems of uuencode.
    PC     - uuxref20
    Unix   - xxencode, xxdecode
    VM/CMS - xxencode

ZIP (.zip)
    This format is most popular on PCs.  Compresses and stores multiple
    files in a single archive.
    PC     - pkz110
    Mac    - UnZip1.02c
    Unix   - unzip4.01
    Amiga  - PKAZip
    Atari  - pkz101-2

ZOO (.zoo)
    This format is popular on many systems.  Compresses and stores multiple
    files in a single archive.
    PC     - zoo201
    Mac    - MacBooz2.1
    Unix   - zoo201
    VM/CMS - zoo
    Amiga  - amigazoo
    VMS    - zoo201
    Atari  - booz
    OS/2   - booz


------------------------------

Date:    Sun, 30 Jun 91 03:50:30 -1000
>From:    Jim Wright <[e-mail]>
Subject: Amiga Anti-viral archive sites, last changed 30 June 1991

Amiga Anti-viral archive sites, last changed 30 June 1991

beach.gal.utexas.edu
        John Perry <[e-mail]>
        This site can be reached through anonymous ftp.
        The Amiga anti-viral archives can be found in the
        directory [ANONYMOUS.PUB.VIRUS.AMIGA].
        This system is running VMS, not Unix.
        The IP address is 129.109.1.207.

ms.uky.edu
        Sean Casey <[e-mail]>
        Access is through anonymous ftp.
        The Amiga anti-viral archives can be found in /pub/amiga/Antivirus.
        The IP address is 128.163.128.6.

uk.ac.lancs.pdsoft
        Steve Jenkins <[e-mail]>
        Service for UK only; no access from BITNET/Internet/UUCP
        Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
        FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
        Pull the file "help/basics" for starter info, "micros/index" for index.
        Anti-Viral stuff is held as part of larger micro software collection
        and is not collected into a distinct area.

ux1.cso.uiuc.edu
        Mark Zinzow <[e-mail]>
        Lionel Hummel <[e-mail]>
        The archives are in /amiga/virus.
        There is also a lot of stuff to be found in the Fish collection.
        The IP address is 128.174.5.59.


------------------------------

Date:    Sun, 30 Jun 91 03:51:01 -1000
>From:    Jim Wright <[e-mail]>
Subject: Apple II Anti-viral archive sites, last changed 30 June 1991

Apple II Anti-viral archive sites, last changed 30 June 1991

brownvm.bitnet
        Chris Chung <[e-mail]>
        Access is through LISTSERV, using SEND, TELL and MAIL commands.
        Files are stored as
                apple2-l xx-xxxxxx
        where the x's are the file number.

uk.ac.lancs.pdsoft
        Steve Jenkins <[e-mail]>
        Service for UK only; no access from BITNET/Internet/UUCP
        Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
        FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
        Pull the file "help/basics" for starter info, "micros/index" for index.
        Anti-Viral stuff is held as part of larger micro software collection
        and is not collected into a distinct area.


------------------------------

Date:    Sun, 30 Jun 91 03:51:32 -1000
>From:    Jim Wright <[e-mail]>
Subject: Atari ST Anti-viral archive sites, last changed 30 June 1991

Atari ST Anti-viral archive sites, last changed 30 June 1991

atari.archive.umich.edu
        Jeff Weiner <[e-mail]>
        Service via FTP and mail, FTP preferred.
        Login as "anonymous", password is your mail address.
        For instructions on the mail server, send the message
                help
        to <[e-mail]>
        "Index" contains complete listing with descriptions.
        "CompInd.Z" contains same list but is compressed.
        "ls-lR.Z" contains compressed ls -lR listing.
        All anti-viral material is contained in ~atari/utilities/virus
        The IP number for this site is 141.211.164.8, but may change.

twitterpater.Eng.Sun.COM
        Steve Grimm <[e-mail]>
        Access to the archives is through mail server.
        For instructions on the archiver server, send
                help
        to <[e-mail]>

uk.ac.lancs.pdsoft
        Steve Jenkins <[e-mail]>
        Service for UK only; no access from BITNET/Internet/UUCP.
        Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft".
        FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
        Pull the file "help/basics" for starter info, "micros/index" for index.
        Anti-Viral stuff is held as part of larger micro software collection
        and is not collected into a distinct area.


------------------------------

Date:    Sun, 30 Jun 91 03:52:03 -1000
>From:    Jim Wright <[e-mail]>
Subject: Anti-viral Documentation archive sites, last changed 30 June 1991

Anti-viral Documentation archive sites, last changed 30 June 1991

cert.sei.cmu.edu
        Kenneth R. van Wyk <[e-mail]>
        Access is available via anonymous ftp, IP number 128.237.253.5.
        This site maintains archives of all VIRUS-L digests, all
        CERT advisories, as well as a number of informational documents.
        VIRUS-L/comp.virus information is in:
                pub/virus-l/archives
                pub/virus-l/archives/predig
                pub/virus-l/archives/1988
                pub/virus-l/archives/1989
                pub/virus-l/archives/1990
                pub/virus-l/docs
        CERT information is in:
                pub/cert_advisories
                pub/cert-tools_archive

csrc.ncsl.nist.gov
        John Wack <[e-mail]>
        This site is available via anonymous ftp, IP number 129.6.48.87.
        The archives contain all security bulletins issued thus far from
        organizations such as NIST, CERT, NASA-SPAN, DDN, and LLNL-CIAC.
        Also, other related security publications (from NIST and others)
        and a partial archive of VIRUS_L's and RISK forums.

lehiibm1.bitnet
        Ken van Wyk <[e-mail]> new: <[e-mail]>
        This site has archives of VIRUS-L, and many papers of
        general interest.
        Access is through ftp, IP address 128.180.2.1.
        The directories of interest are VIRUS-L and VIRUS-P.

uk.ac.lancs.pdsoft
        Steve Jenkins <[e-mail]>
        Service for UK only; no access from BITNET/Internet/UUCP
        Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
        FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
        Pull the file "help/basics" for starter info, "micros/index" for index.
        Anti-Viral stuff is held as part of larger micro software collection
        and is not collected into a distinct area.

unma.unm.edu
        Dave Grisham <[e-mail]>
        This site has a collection of ethics documents.
        Included are legislation from several states and policies
        from many institutions.
        Access is through ftp, IP address 129.24.8.1.
        Look in the directory /ethics.


------------------------------

Date:    Sun, 30 Jun 91 03:52:34 -1000
>From:    Jim Wright <[e-mail]>
Subject: IBMPC Anti-viral archive sites, last changed 30 June 1991

IBMPC Anti-viral archive sites, last changed 30 June 1991

beach.gal.utexas.edu
        John Perry <[e-mail]>
        This site can be reached through anonymous ftp.
        The IBMPC anti-viral archives can be found in the
        directory [ANONYMOUS.PUB.VIRUS.PC].
        This system is running VMS, not Unix.
        The IP address is 129.109.1.207.

risc.ua.edu
        James Ford <[e-mail]> <[e-mail]>
        This site can be reached through anonymous ftp.
        The IBM-PC anti-virals can be found in pub/ibm-antivirus.
        Uploads to pub/ibm-antivirus/00uploads.  Uploads are screened.
        Requests to [e-mail] for UUENCODED files will be filled
        on a limited basis as time permits.
        The IP address is 130.160.4.7.

uk.ac.lancs.pdsoft
        Steve Jenkins <[e-mail]>
        Service for UK only; no access from BITNET/Internet/UUCP
        Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
        FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
        Pull the file "help/basics" for starter info, "micros/index" for index.
        Anti-Viral stuff is held as part of larger micro software collection
        and is not collected into a distinct area.

ux1.cso.uiuc.edu
        Mark Zinzow <[e-mail]>
        This site can be reached through anonymous ftp.
        The IBMPC anti-viral archives are in /pc/virus.
        The IP address is 128.174.5.59.

vega.hut.fi
        Timo Kiravuo <[e-mail]>
        This site (in Finland) can be reached through anonymous ftp.
        The IBMPC anti-viral archives are in /pub/pc/virus.
        The IP address is 130.233.200.42.

wsmr-simtel20.army.mil
        Keith Peterson <[e-mail]>
        Direct access is through anonymous ftp, IP 192.88.110.20.
        The anti-viral archives are in PD1:<MSDOS.TROJAN-PRO>.
        Please get the file 00-INDEX.TXT and review it offline.
        NOTE:
        There are also a number of servers which provide access
        to the archives at simtel.
        WSMR-SIMTEL20.Army.Mil can be accessed using LISTSERV commands
        from BITNET via LISTSERV@NDSUVM1, LISTSERV@RPIECS and in Europe
        from EARN TRICKLE servers.  Send commands to TRICKLE@<host-name>
        (for example: TRICKLE@AWIWUW11).  The following TRICKLE servers
        are presently available: AWIWUW11 (Austria), BANUFS11 (Belgium),
        DKTC11 (Denmark), DB0FUB11 (Germany), IMIPOLI (Italy),
        EB0UB011 (Spain) and TREARN (Turkey).


------------------------------

Date:    Sun, 30 Jun 91 03:53:05 -1000
>From:    Jim Wright <[e-mail]>
Subject: Macintosh Anti-viral archive sites, last changed 30 June 1991

Macintosh Anti-viral archive sites, last changed 30 June 1991

beach.gal.utexas.edu
        John Perry <[e-mail]>
        This site can be reached through anonymous ftp.
        The Macintosh anti-viral archives can be found in the
        directory [ANONYMOUS.PUB.VIRUS.MAC].
        This system is running VMS, not Unix.
        The IP address is 129.109.1.207.

dftnic.gsfc.nasa.gov
        Brian Lev <[e-mail]> <SDCDCL::LEV> <LEV@DFTBIT>
        This site offers the "MacSecure" package, made up of John Norstad's
        Disinfectant, and a pair of locally developed HyperCard stacks:
        Joe McMahon's "Anti-Viral Doc" and Brian Lev's "MacHelper".
        Floppy disk:
                Advanced Data Flow Technology Office
                Code 930.4
                Goddard Space Flight Center
                Greenbelt, MD 20771 (Attn: Brian Lev)
        DECnet Copy from DFTNIC::CLDATA:[ANONYMOUS_FTP.FILES.MAC]
                BinHex (ASCII) format as MACSECURE31.HQX
                binary format as MACSECURE31.SEA
        Anonymous FTP from DFTNIC.GSFC.NASA.GOV (128.183.10.3)
                BinHex (ASCII) format as [.FILES.MAC]MACSECURE31.HQX
                binary format as [.FILES.MAC]MACSECURE3.SIT

ifi.ethz.ch
        Danny Schwendener <[e-mail]>
        Interactive access through DECnet (SPAN/HEPnet):
                $SET HOST 57434  or $SET HOST AEOLUS
                Username: MAC
        Interactive access through X.25 (022847911065) or Modem 2400 bps
        ([phone]):
                # CALL B050 <cr><cr>
                Username: MAC
        Files may also be copied via DECnet (SPAN/HEPnet) from
                57434::DISK8:[MAC.TOP.LIBRARY.VIRUS]

rascal.ics.utexas.edu
        Werner Uhrig <[e-mail]>
        Access is through anonymous ftp, IP number is 128.83.138.20.
        Archives can be found in the directory mac/virus-tools.

scfvm.bitnet
        Joe McMahon <[e-mail]>
        Access is via LISTSERV.
        SCFVM offers an "automatic update" service.  Send the message
                AFD ADD VIRUSREM PACKAGE
        and you will receive updates as the archive is updated.
        You can also subscribe to automatic file update information with
                FUI ADD VIRUSREM PACKAGE

sumex-aim.stanford.edu
        Bill Lipa <[e-mail]>
        Access is through anonymous ftp, IP number is 36.44.0.6.
        Archives can be found in /info-mac/virus.
        Administrative queries to <[e-mail]>.
        Submissions to <[e-mail]>.
        There are a number of sites which maintain shadow archives of
        the info-mac archives at sumex:
        * MACSERV@PUCC            services the Bitnet community
        * LISTSERV@RICE           for e-mail users
        * FILESERV@IRLEARN        for folks in Europe

uk.ac.lancs.pdsoft
        Steve Jenkins <[e-mail]>
        Service for UK only; no access from BITNET/Internet/UUCP
        Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
        FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
        Pull the file "help/basics" for starter info, "micros/index" for index.
        Anti-Viral stuff is held as part of larger micro software collection
        and is not collected into a distinct area.

wsmr-simtel20.army.mil
        Robert Thum <[e-mail]>
        Access is through anonymous ftp, IP number 192.88.110.20.
        Archives can be found in PD3:<MACINTOSH.VIRUS>.
        Please get the file 00README.TXT and review it offline.


------------------------------

Date:    Sun, 30 Jun 91 03:53:36 -1000
>From:    Jim Wright <[e-mail]>
Subject: Unix Anti-viral and security archive sites, last changed 30 June 1991

Unix Anti-viral and security archive sites, last changed 30 June 1991

funic.funet.fi
        Jyrki Kuoppala <[e-mail]>
        Accessible through anonymous ftp, IP number 128.214.6.100.
        Directory pub/unix/security contains programs to help in
        security, pub/doc/security contains various documents about
        security in general and unix security (like the worm
        documents)

wuarchive.wustl.edu
        Chris Myers <[e-mail]>
        Accessible through anonymous ftp, IP number 128.252.135.4.
        A number of directories can be found in ~ftp/usenet/comp.virus/*.

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 114]
******************************************
VIRUS-L Digest   Tuesday,  2 Jul 1991    Volume 4 : Issue 115

Today's Topics:

Rumors
Recalciterant infection with Frodo (PC)
$MUSTAFA, new virus? (PC)
Retrospect Remote vs. Gatekeeper (Mac)
Disk Boot Failure?! (PC)
Re: Can such a virus be written .... (PC)
GUARD - prevents h.d. infection via floppy boot (PC)
Re: Virus protection: what to use
New files on MIBSRV (PC)
Disinfectant 2.5? (Mac)
Re: Two versions of SCANV80.ZIP? (PC)
re: Words

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Sat, 29 Jun 91 02:05:00 +0000
>From:    William Hugh Murray <[e-mail]>
Subject: Rumors

> I just received word of a virus that was encountered during a Mac
> System 7 installation.  Both the keyboard and mouse DIED on three
> machines that just had System 7 installed on them.  The customer
> then attached a voltage meter to the ADB port of a fourth machine
> only to find a unusually high reading.  It appears the virus
> destroys chips on the mouse and keyboard.

I am glad I do not have his job.  I  know that Ken is very careful
about what he posts.  I am reluctant to second guess him.   However,
in the case of this posting, I must.

The posting is potentially more damaging than the damage that it seeks
to avert.

First, it is hearsay.  The author does not cite his source, and claims
no first-hand knowledge of the events that he reports.

Second, it appeals to fear of permanent and irreversible damage from a
program.  Such appeals to fear can never be justified except by carefully
tested conclusions.

Third, it speculates on hardware damage from indirect evidence.  I can
think of far more likely causes for keyboards and mouses not to work
than destruction of chips, particularly, if as the reporter speculates,
the cause is somehow related to the installation of software.

Fourth, while second-hand, it reports something so unlikely as to make
any responsible reporter question his sources and hold his water.  That
is, it reports that programmable behavior of a computer caused permanent
damage to the computer hardware.  The only evidence that any damage that
may have occurred was software related was that the same code had just
been installed on all of them.  Sorry, that is not sufficient evidence
that any damage was software related.

A report of an "unusually high (output voltage) reading" is used to
support the conclusion that the damage was caused by software, when in
fact, that should lead one to the far more likely conclusion that any
damage was related to an abnormally high input voltage.

Rumors of viruses are almost as damaging to public trust as viruses
themselves.   One should not attribute damage to viruses without cause.
One may not justify premature reports on the basis that the virus is
very damaging.  The greater the power attributed to the virus, the
greater, not the lesser, the responsibility to report only what one
knows with a very high level of confidence and authority.  "I just
received word" will not cut it.

I will be very surprised if these events are at all related to software.
If the cause was software, I will be extremely surprised if the symptoms
reported were caused by destruction of chips.  I will not be surprised
to learn that they did not happen as reported, did not happen at all, or
are pure fantasy.  Even if they happened exactly as reported, the report
is still premature and irresponsible.
____________________________________________________________________
William Hugh Murray                     203-966-4769
Information System Security             203-326-1833 (CELLULAR)
Consultant to Deloitte & Touche         203-761-3088
Wilton, Connecticut                     email: [e-mail]
                                        [e-mail]
                                        MCI-Mail: 315-8580
                                        TELEX: 6503158580
                                        FAX: [phone]
                                        Compu-Serve: 75126,1722
21 Locust Avenue, Suite 2D              DASnet: [DCM1WM]WMURRAY
New Canaan, Connecticut 06840           PRODIGY: DXBM57A

[Ed. The moderator's response: VIRUS-L/comp.virus receives a great
number of messages which appeal to fear and/or are purely hearsay.
Long time subscribers will no doubt recognize past examples such as
discussions of disk drives writing to write-protected disks, viruses
destroying monitors, etc.  I generally send a response to the author
requesting that he/she cite some reference and/or provide complete
technical details of any testing and so forth; I have yet to get a
response to such a request...  Occasionally, however, one of two
things can happen.  The first is that I accidentally overlook and
accept the posting.  Mistakes can happen, but I try my best to avoid
them and I try even harder to learn from my mistakes.  The second is
that I decide to pass the message on under the assumption that the
vast pool of technical expertise that we have out on the list will
quickly and decisively dispell the poster's claims.

I also would like add the comment that VIRUS-L, like all/most _public_
discussion forums, cannot guarantee the technical authenticity of its
contents.  The contents of the list are up to the individual
subscribers.  As such, I would strongly recommend treating all
(outlandish) claims with a grain of salt until they can be
independently verified.]

------------------------------

Date:    Sun, 30 Jun 91 20:31:32 +0700
>From:    Aviel Roy-Shapira <[e-mail]>
Subject: Recalciterant infection with Frodo (PC)

Help please!  I have a recalciterant infection by Frodo or 4096.  I am
not sure about the source of the infection, but somehow it got into my
system.  Clean (V. 77) cleaned the disk alright, but the infection
keeps poping up.  It has become even wierder.  Both Clean, Virus Scan,
and F-Fchk (115) report that all the files on my hard disk are free
from the virus.  But, if I boot from the hard disk, and I run
F-SYSCHK, it says the virus is lurking in memory.  I don't get this
warning if I boot from a floppy.

My config.sys file contains Device=DMDrvr.bin, Device=f-driver.sys,
files=40 and buffers=20.  I don't run any programs or TSR from my
autoexec, which simply states the path and sets a couple of
environment variable.  DMDrvr.bin appears to be clean, as its length
is 8000 bytes or so and it didnot change.

I thought that Frodo was only a COM and EXE file infector, yet it
somehow entered my system and refuses to leave. Any ideas?
Aviel

------------------------------

Date:    Mon, 01 Jul 91 17:52:00 +1200
>From:    "John, Registry" <[e-mail]>
Subject: $MUSTAFA, new virus? (PC)

Hi,
    Anybody heard of a possible PC virus called $MUSTAFA?
    Don't know too much about it at the moment.  The mouse has stopped
working.  If you look at device drivers, there is one at
       Memory    Size Driver    Program  Attributes
                   NUL       MSDOS    C
    0AAD-0BA7 3.9K $MUSTAFA           CS
    .
    .
    .

There is a file open:
       Name       Ext    Program
    AUX
    CON
    PRN
    $MUSTAFA     (1041)

A memory map shows:
    .
    .
    .
    1036 - 103F  0.2K   TRUMOUSE Environment
    1040 - 2193   69K   (1041)
    2194 - 23BD  8.7K   TRUMOUSE
    .
    .
    .

The partition table and boot sectors look o.k.  Scan 77 doesn't pick
it up.  I am getting Scan 80 (hopefully) and will try that.  If you do
a whereis $mustafa.* it finds it on every directory on the disk (2.7K
long. Looking at the actual directory entries the file doesn't exist.

If anybody has any more info for me please e-mail.

    John

------------------------------

Date:    01 Jul 91 02:06:56 -0400
>From:    [e-mail] (Edward J. Huff)
Subject: Retrospect Remote vs. Gatekeeper (Mac)

I ran the Retrospect 1.3 remote updater, which sends a new version of
the Retrospect Remote cdev across the network.  Gatekeeper 1.1.1 and
1.2 both log the PBSetCatInfo from '' to 'cdev' operation to whatever
application happened to be running.

The basic problem is: gatekeeper depends on trusting certain programs
to be permitted certain operations, but sometimes, operations can be
performed by an INIT such as Retrospect Remote, while that program is
the "current application," and gatekeeper fails to notice that the
operation was not initiated by the trusted program.

------------------------------

Date:    Mon, 01 Jul 91 12:28:37 +0000
>From:    [e-mail] (Greg Burlile)
Subject: Disk Boot Failure?! (PC)

Could a virus cause the "Disk Boot Failure" DOS error message to
appear?  We've had this problem with two of our machines.  One of them
we had to reformat so that would could finally get the PC to boot from
the hard drive.  The other computer we were able to boot from diskette
and then reboot from the hard drive.  Prior to that we had a problem
with several computers (including the two I mentioned above) having
their root directory files erased (including the hidden system files).
Could someone please give me some input as to why this is happening.
Is it a virus?  I've run F-PROT 1.13 on these machines and nothing
came up.  I just downloaded a copy of 1.16 and will see if it finds
anything.

------------------------------

Date:    Mon, 01 Jul 91 13:40:17 +0000
>From:    [e-mail] (Matthew F Ringel)
Subject: Re: Can such a virus be written .... (PC)

[e-mail] (Pete Lucas) writes:
>until the virus has had a look at whats there. Of course the write-protect
>notch/slide is 99.99% effective in my experience at preventing any
>illicit writes; you would, of course, have write-protected any diskette
>you put in the drive before doing the hypothetical DIR command, wouldnt
>you?
>          Pete Lucas

Speaking of that...
    Is it possible for a virus to circumvent an IBM's
write-protection of a disk (if the disk is protected in the stndard
way of covering the notch), or is it something physical that no piece
of software can get around?

Any idea?  I'd love to hear them.
                        -Matthew


}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}}{}{}{}{}{}{}{}{
Matthew F. Ringel                   {}  Internet:[e-mail]
     ...and God saw the light...    {}           [e-mail]
..and said that it was pretty neat.{}    Columbia University Football #1!

------------------------------

Date:    Mon, 01 Jul 91 15:20:00 +0300
>From:    Y. Radai <[e-mail]>
Subject: GUARD - prevents h.d. infection via floppy boot (PC)

  About half a year ago, someone asked whether there was a way of
preventing infection of one's hard disk on cold-boot when an infected
diskette happens to be in drive A:.  As I hinted a couple of times, I
would soon be announcing a program to do this.  Well, it's called
GUARD and is now available in uuencoded ZIPped form to anyone who
requests it from me by e-mail.
  Some people on this list expressed the opinion that this wouldn't
work on a cold boot, or against partition-record viruses, or that it
could only detect infection but not prevent it, or that it would re-
quire hardware or a special BIOS.  Well, GUARD prevents hard-disk
infection on floppy boot (even cold boot) without using either hard-
ware or a special BIOS.

  The basic idea is as follows:  When you install GUARD, it zeroes out
several bytes of each entry of the partition table (storing the origi-
nal bytes elsewhere in the partition record), so that these partitions
are not recognized as DOS partitions when booting from a diskette, and
it inserts code in the partition record which resets these bytes when
booting is performed from the hard disk.  A command GUARD -G in the
AUTOEXEC.BAT file of the hard disk zeroes the bytes again, thus re-
storing the protection for the next diskette boot.
  Because of the fact that the hard-disk partitions are non-DOS par-
titions when booting from a diskette, no boot-sector or file virus can
infect the hard disk.  A partition-record virus will infect the parti-
tion record of the hard disk *temporarily*, but the viral code will be
overwritten by GUARD's uninfected code the next time booting is per-
formed from the hard disk.

  There's nothing original in the idea of modifying the partition
record for this purpose, although I haven't seen a program which deals
with p.r. viruses in this way.  Note also that it does not rely on a
device driver or any other code outside of the p.r., as most other
programs of this type do.  Another feature is that you can protect
*selected partitions* of your hard disk(s).

  GUARD also contains an option to require typing of a password in
order to use the computer after booting from the hard disk.

  Can GUARD be circumvented by a directed attack?  Of course, but what
anti-viral program can't?  (The closest thing to an exception seems to
be a carefully designed checksum program activated after booting from
a clean diskette.)  However, it's effective against all viruses which
do not mount a directed attack against this type of defense (which
includes all viruses known today).

  Note: I am not the author of GUARD.  I simply beta-tested it, sug-
gested numerous improvements, and wrote the documentation for it.  You
are invited to try it out ("gamma-test" it) and to send me your com-
ments, which I will reply to and/or forward to the author.  (Eventual-
ly GUARD will be uploaded to Simtel20 and other servers as shareware.)

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]
                                     [e-mail]

------------------------------

Date:    Mon, 01 Jul 91 15:38:00 +0300
>From:    Y. Radai <[e-mail]>
Subject: Re: Virus protection: what to use

  Aryeh Goretsky gave a good description of the three main types of
anti-viral software.  I think he missed a few important points, how-
ever, so I'd like to contribute a few additions to what he wrote.

 Concerning "filters" (or as I call them, generic monitoring pro-
grams), he writes:
>Filters have the
>advantage of being able to detect new viruses because they are not
>looking for specific viruses, but rather virus-methods.

Correct, but there is another advantage (in comparison to the other
methods he mentions, which can only detect infections *after* they
have occurred): filters can *prevent* infection from occurring at all.

  He then mentions three disadvantages of filters.  However, there are
two others: (1) They can't prevent anything which happens before they
go resident (in particular, boot sector infections).  (2) Being resi-
dent programs, they are more vulnerable to neutralization or circum-
vention by a hostile program than is a non-resident program.

  Concerning "change checkers" (modification detectors), he writes:
>The advantages to change checkers
>are that they will detect known and unknown viruses, like the filter,

True, but a filter can also be effective against immediate-acting
*Trojans*, something that is not true of a change checker.

>it's been theorized that if
>the method of change checking is known, a virus could be written to
>add itself to files in such a way that a checksum identical to the
>known (good) checksum is generated;

This is not possible with a CRC or cryptographic algorithm if each
user's checksums are based on a different key unknown to others and
his table of checksums is inaccessible to a hostile program.  (These
two conditions cannot be achieved in inter-machine transfer of files
to arbitrary users, but they can be achieved when modification takes
place on a given computer, which is what is normally assumed when
discussing viruses.)

  Turning to [known-virus] scanners, he writes:
>And of course, as more
>viruses are added, the scanner gets s l o w e r.

This is true of *most* scanners, but not all of them.  By using a
hashing technique, the scanning time can be kept constant, at the
price of somewhat increased program size.

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]
                                     [e-mail]


------------------------------

Date:    Mon, 01 Jul 91 11:10:06 -0500
>From:    James Ford <[e-mail]>
Subject: New files on MIBSRV (PC)

The following files have been uploaded to risc.ua.edu in the directory
pub/ibm-antivirus for anonymous ftping:

scanv80.zip
netscn80.zip
vshld80.zip
clean80.zip
virx15.zip

One last note:  MIBSRV.MIB.ENG.UA.EDU has been removed.  It is probably
going to make someone a nice boat
- ----------
Behind every successful man is a woman who made it necessary.
- ----------
James Ford -  [e-mail], [e-mail]
              The University of Alabama (in Tuscaloosa, Alabama)

------------------------------

Date:    Mon, 01 Jul 91 12:39:33 -0700
>From:    [e-mail] (Rob Slade)
Subject: Disinfectant 2.5? (Mac)

Recently, the Fidonet "Warnings" echo carried a note about Mac users
having to upgrade to Disinfectant 2.5.  I replied with the information
from John Norstad's posting here a while back:

==========

>From: [e-mail] (John Norstad)
Subject: Disinfectant and System 7 (Mac)
Date: 20 May 91 01:50:16 GMT

Thanks to an error in Apple's Compatibility Checker, I've been deluged
with requests for information on Disinfectant 2.5.

If you have installed the Disinfectant INIT on your system, Apple's
Compatibility Checker incorrectly reports that it is incompatible with
System 7, and it recommends that you get version 2.5.

There is no Disinfectant 2.5, and there won't be one! Disinfectant 2.4
works fine with System 7, provided you leave the Disinfectant INIT in

==========

I have now received the following reply:

==========

06/30/91 19:10:49
>From: JOHN LENKO
Subj: REPLY TO MSG# 12992 (DISINFECTANT 2.5)
Unbelievers get viruses...at least in this case they do!

This is John's friend Chris, the source for the info..

I already have 2.5, and it is already posted on DDCBBS, in case you do
not believe that there is a version 2.5.  I would suggest looking into
it, for it is not only System 7.0 compatible, but is also able to
recognize the new strain of ZUC, strain C, that is....
- --- TBBS v2.1/NM
 * Origin: Doppler/Deep Cove TBBS - Richmond, B.C. (153/915)

=========

What gives?

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Tue, 02 Jul 91 00:37:39 +0000
>From:    [e-mail] (McAfee Associates)
Subject: Re: Two versions of SCANV80.ZIP? (PC)

[e-mail] (Rob Slade) writes:
>I retrieved SCANV80.ZIP from the wuarchive.wustl.edu mirror of
>SIMTEL20, but when I went to repost it on a local board found a
>different version.  Both versions appear to be authentic, with some
>minor differences in text files:
[listing of ZIP file contents deleted here...]
>It seems the only differences are found in:
>              README.1ST
>              REGISTER.DOC
>              SCANV80.DOC
>              VIRLIST.TXT
>with the addition of two files:
>              NETSCN80.DOC
>              VSHLD80.DOC

Oops.  The SCAN zip file was released with two extra doc files in it
accidentally.  It was replaced after it this was discovered a few
hours later, but apparently a few copies are circulating...  It's no
cause for alarm, the only difference being that the ZIP file with the
extra two files may take a bit longer to download.

Regards,

Aryeh Goretsky
McAfee Associates Technical Support
- --
McAfee Associates     | Voice [phone]    | [e-mail]
4423 Cheeney Street     | FAX   [phone]    | (Aryeh Goretsky)
Santa Clara, California     | BBS   [phone]    |
95054-0253  USA         | v.32  [phone]    | [e-mail]
ViruScan/CleanUp/VShield | HST   [phone] | (Morgan Schweers)

------------------------------

Date:    Mon, 01 Jul 91 20:39:06 -0700
>From:    [e-mail] (Rob Slade)
Subject: re: Words

[e-mail] (Johnathan Vail) writes:

> virus - a piece of code that is executed as part of another program
>     and can replicate itself in other programs.  The analogy to real
>     viruses is pertinent ("a core of nucleic acid, having the ability to
>     reproduce only inside a living cell").  Most viruses on PCs really are
>     viruses.
>
> worm - a program that can replicate itself, usually over a network.  A
>     worm is a complete program by itself unlike a virus which is part of
>     another program.  Robert Morris's program, the Internet Worm, is an
>     example of a worm although it has been mistakenly identified in the
>     popular media as a virus.
>     bomb.

Question:

Given that under these definitions boot sector infectors, "spawning"
viri and items such as Mac's WDEF are excluded from "virus", does that
make them all "worms"?

If so, you will have to define "most viruses on PCs", since many of
the more successful PC viri are BSI's.

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 115]
******************************************
VIRUS-L Digest   Wednesday,  3 Jul 1991    Volume 4 : Issue 116

Today's Topics:

General definition part 1 (general)
Requirements for Virus Checkers (PC)
New Release of VIRx: Version 1.6 now available (PC)
FROD/4096 (PC)
Disinfectant 2.5 (Mac)
re: Can such a virus be written... (PC) (Amiga)
Words, Words, Words
Re: Dos Boot control with pascal. (PC)
Disinfectant 2.5, To be or not to be? (Mac)
Re: Software pricing
IBM Write-Protection (was: Can such a virus be written ... ) (PC)
sideshow on doom2:reply (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Mon, 01 Jul 91 20:59:49 -0700
>From:    [e-mail] (Rob Slade)
Subject: General definition part 1 (general)

DEFGEN1.CVP   910701
                Towards a Definition of computer Viral Programs

The "man on the street" is now often aware of the term "computer
virus" even if he (or she) does not use a computer.  However, it is
often the case that those who are otherwise technically literate do
not understand some of the implications of the phrase.  This is not
surprising in that the term is slang, is often misused, and that
"hard" information is difficult to come by.

It is important to know what a computer virus is if you are going to
defend yourself against the many that are "out there."  It is also
important to know what a computer virus is not.  There are other types
of programs and situations which can do damage to your computer or
data, and many of these will not be caught by the same methods which
must trap viral programs.

A biological analogy, which we find in the dictionary, is helpful.
The Oxford English Dictionary, which speaks of:
    "... a moral or intelletual poison, or poisonous influence..."
while satisfying to the wounded ego of those who have been hit is not
terribly helpful in a technical sense.  Webster, however, steers us in
a more helpful route in stating that a virus is:
    "... dependent on the host's living cells for their growth and
reproduction..."

By elimating the biological references, we can come to the definition
that a virus is an entity which uses the resources of the host to
spread and reproduce itself without informed operator action.  Let me
stress here, the word "informed."  A virus cannot run completely on
its own.  The computer user must always take some action, even if it
is only to turn the computer on.  This is the major strength of a
virus: it uses *normal* computer operations to do its dirty work, and
therefore there is no single identifying code that can be used to find
a viral program.

I must make mention, before I continue, of the work of Fred Cohen.
Dr. Cohen is generally held to have coined the term "computer virus"
in his thesis, published in 1984.  However, his definition covers only
those sections of code which, when active, attach themselves to other
programs.  This, however, neglects many of the programs which have
been most successful "in the wild".  Many researchers still insist on
this definition, and therefore use other terms such as "worm" and
"bacterium" for those viri which do not attack programs.

copyright Robert M. Slade, 1991   DEFGEN1.CVP   910701

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Tue, 02 Jul 91 12:30:07
>From:    [e-mail]
Subject: Requirements for Virus Checkers (PC)

>From:    Robert McClenon <[e-mail]>

>     The second clause is true but sadly irrelevant.  I wish every
>developer were as attentive as Ross is to complaints.  I wish every
>vendor were as responsive as Ross and Microcom are.  For those reasons
>the first clause is good advice in general but not worth fighting
>over.

<Blush> and thanks, but I think we could do better, frankly.  All
that, however, requires that users *actively* take part in the process
of product development.  If you're using a company's product and
there's stuff about it that you don't like, think is needed, want in
the next version --- call them up and tell them.  Microcom actually
pays people to listen to your suggestions (and the odd complaint, I
guess) and writes them up.  When we start talking about what to
include in the next version of the code, the end user (the people with
the money to buy the product) dictate what we stick into that next
release.  Be vocal!

This isn't just for anti-virus products, of course: I've been involved
in the commercial programming end of a number of products.  We always
work in an ideal world of what we think the world wants and
neds...until them pesky end-users start telling us where we're
wrong....

Heck, *I* was under the impression that everybody *loved* command line
interfaces (maybe my UNIX background showing through?) --- but it
seems people are in love with those hgorrid little drop and shadow
boxes.

Guess what Version 2.0 has in it....

Ross

------------------------------

Date:    Tue, 02 Jul 91 12:37:00
>From:    [e-mail]
Subject: New Release of VIRx: Version 1.6 now available (PC)

There were some problems with Version 1.5.  Version 1.6 is now
available on CIS, my BBS (212-889-6438) and, shortly, on SIMTEL-20.

Hightlights:
                   What's New In VIRx Version 1.6
                   ==============================

Date: 7/01/91

   1.   VIRx Version 1.6 now detects six newly discovered viruses,
   bringing the total count to just over 500.

   2.   VIRx now indicates whether an infected compressed program
   was infected before or after the compression (PKLITE and LZEXE).
   This was trivial to implement, but a useful addition.

   3.   Another few cycles were shaved off our decompression routines:
   experience pays.  For those wondering, all decompression routines
   are completely internal and done in memory --- and always have been.


Problems Corrected from v1.5:

   1.    False positives for the "Sathanyc/Goblin/Necrop" viruses.
   VIRx Version 1.5 was incorrectly identifying "ICE'ed" programs
   as infected.  An example of this was the well known TIMESET program:
   our apologies and gratitude to Peter Petrakis for being a good sport
   about our mistake.

   2.    Occasional false positives for "Scrnched" files: fixed.

   3.    The P1 Virus string was occasionally left in DOS buffers: another
   scanner program which apparently used the same string would make
   erroneous reports of an active P1 Virus in memory.  This has been fixed.

   4.     Due to similar templating of the V2P6 Virus, VIRx would find
   a possible infection in the VDEFEND program.  This was rectified.

------------------------------

Date:    Tue, 02 Jul 91 15:31:51 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: FROD/4096 (PC)

>From:    Aviel Roy-Shapira <[e-mail]>

>Clean (V. 77) cleaned the disk alright, but the infection
>keeps poping up.  It has become even wierder.  Both Clean, Virus Scan,
>and F-Fchk (115) report that all the files on my hard disk are free
>from the virus.  But, if I boot from the hard disk, and I run
>F-SYSCHK, it says the virus is lurking in memory.  I don't get this
>warning if I boot from a floppy.

This being the second time I have seen this type of posting with
regard to Frodo/4096 & have two comments to make: the 4096 is a
"stealth" virus & goes resident in memory. At least two of the scan
programs mentioned will detect the 4096 in memory unless they are
explicitly told not to (/nomem) in which case use will infect every
file on the disk (yes I did, publicly, once, nevermore)

However, this is one of the viruses that can be detected very easily
in memory using CHKDSK. Most clean 640k PCs will report "655360 bytes
total memory".  If the 4096 is resident, this value will be somewhere
below 652xxx bytes (CMA- do not have my notes here). If you have
655360 (everyone got it memorized now ?)  you do not have the 4096
"classic" version.

                    Cooly (monsoon season has started),

                        Padgett

------------------------------

Date:    Tue, 02 Jul 91 15:29:03 -0400
>From:    Ed Maioriello <[e-mail]>
Subject: Disinfectant 2.5 (Mac)

All,

I have seen many questions regarding the compatibility of Disinfectant
2.4 with Macintosh System 7 and the availability of Disinfectant 2.5.

I have experienced no problems using Disinfectant 2.4 with System 7,
though I understand the Disinfectant init should be left in the System
Folder proper - not placed in the Extensions folder.

The same is true of Disinfectant 2.5 and its init which is available
off Sumex-aim.stanford.edu via anonymous ftp now.

Ed Maioriello                                Bitnet:    EMAIORIE @ UGA
University Computing & Networking Servs.     Internet:  [e-mail]
University of Georgia
Athens, Ga. 30602                            (404)-542-8780
                    Where are the Snowdens of yesteryear?

------------------------------

Date:    Tue, 02 Jul 91 19:12:28 -0500
>From:    Finnegan Southey <[e-mail]>
Subject: re: Can such a virus be written... (PC) (Amiga)

     Fridrik Skulason writes:
>However, the question was
>whether a virus-infected diskette could infect the system, when the
>user issued a 'DIR' command.

>The answer to that question is a definite NO - on a PC, that is - but
>I am not sure if the same applies to the Amiga or the Mac - perhaps
>omebody else can clarify that.

     This is definatly possible on Amiga's running Kickstart/Workbench
1.3 or lower.  All AmigaDos commands are executable files so a file
infector could easily use the dir or list commands.  I've heard that
Kickstart 2.0 has most AmigaDos commands in ROM (the ROMs are shipping
now) but I'm not sure.  That would be great from the virus
perspective...

- -----------------------------------------------------------------------------
 Finnegan Southey - CCS HELP DESK, University of Guelph, Ontario, CANADA
        BitNet: ACDFINN.VM.UOGUELPH.CA  CoSy: [e-mail]
            You are in a maze of twisty little passages, all alike.

------------------------------

Date:    02 Jul 91 23:20:29 -0400
>From:    Robert McClenon <[e-mail]>
Subject: Words, Words, Words

     >Date:    Mon, 01 Jul 91 20:39:06 -0700
>From:    [e-mail] (Rob Slade)
>Subject: re: Words

>[e-mail] (Johnathan Vail) writes:
>> virus - a piece of code that is executed as part of another
>>program
>>     and can replicate itself in other programs.  The analogy to
>>real
>>     viruses is pertinent ("a core of nucleic acid, having the
>>ability to
>>     reproduce only inside a living cell").  Most viruses on PCs
>>really are
>>     viruses.

>> worm - a program that can replicate itself, usually over a
>>network.  A
>>     worm is a complete program by itself unlike a virus which is
>>part of
>>     another program.  Robert Morris's program, the Internet
>>Worm, is an
>>     example of a worm although it has been mistakenly identified
>>in the
>>     popular media as a virus.
>
>Question:
>
>Given that under these definitions boot sector infectors,
> "spawning" viri and items such as Mac's WDEF are excluded from
> "virus", does  that make them all "worms"?
>
>If so, you will have to define "most viruses on PCs", since many
>of the more successful PC viri are BSI's.

     This is very much a terminological issue at two levels.  However,
I would agree with Vail that the definitions are sound and do not
require a modification of the statements that he made.  The real issue
is: "What is a program?"  I submit that the Master Boot Record of a PC
is a special-purpose program.  Therefore a Boot Sector Infector such
as Stoned is a virus using Vail's definition.  Any code executed in
the Desktop is a program, even if it is a Trojan horse program because
it is taking advantage of a weakness in System less than 7.0.
Therefore WDEF is a program infecting virus.  A program is any
stand-alone sequence of executable instructions, not just those
executed by a valid call to the operating system.  Slade has a good
question.  He is basically demanding clarification of terminology.  We
need that.  Stoned is a virus.  WDEF is a virus.  The Morris worm was
not a virus.  It was a worm.

          Robert McClenon
          Neither my employer nor anyone else paid me to say this.

------------------------------

Date:    Wed, 03 Jul 91 05:30:58 +0000
>From:    [e-mail] (David Conrad)
Subject: Re: Dos Boot control with pascal. (PC)

[e-mail] writes:
>[e-mail] (Steve Shimatzki) writes:
>> Does anyone know how I would make a program to boot off of floppy
>> (fist, not boot, and then run...) or add it to the existing boot,
>> so that I could have my program run first.
>>
>> I got curious about the new portable computer security software, that
>> makes sure that it is booted with a 'KEY' disk, and I wanted to do
>> something like that, but as PD  (commercial is 99$!!!!)
>>
>(1) you can encode the hard disk (scramble sectors) so you have to boot off
>    a special floppy that replaces the BIOS to decode them correctly,

Please, I have enough nightmares after my hard disk made that funny
sound last week, I don't need the disk to be in some weird,
non-standard and insufficiently well-tested format, thank you.

>[Mark suggests that the BIOS could be replaced, and that the BIOS writers
>need to help out the security/anti-viral effort.  Amen.]
>
>Mark Aitchison.

This has little to do with pascal, so I'm directing followups to
comp.virus.

David R. Conrad
[e-mail]
- --
=  CAT-TALK Conferencing Network, Computer Conferencing and File Archive  =
- -  1-313-343-0800, 300/1200/2400/9600 baud, 8/N/1. New users use 'new'    -
=  as a login id.  AVAILABLE VIA PC-PURSUIT!!! (City code "MIDET")        =
   E-MAIL Address: [e-mail]

------------------------------

Date:    Wed, 03 Jul 91 09:20:00 -0400
>From:    "Mark Nutter, Apple Support" <[e-mail]>
Subject: Disinfectant 2.5, To be or not to be? (Mac)

[e-mail] quotes from John Norstad:

>>There is no Disinfectant 2.5, and there won't be one! Disinfectant 2.4
>>works fine with System 7, provided you leave the Disinfectant INIT in

He then quotes "John's friend Chris" as saying:

>>I already have 2.5, and it is already posted on DDCBBS, in case you do
>>not believe that there is a version 2.5.  I would suggest looking into

He then asks:

>=========
>
>What gives?
>
>=========

I think the answer lies in the dates of the messages.  I downloaded
Disinfectant 2.5 yesterday (July 2), and noted in the help file that
John is working on a 3.0 version that will be a lot more at home in
System 7.  Presumably, he was already working on this on 20 May 91,
when his original message was posted, and was therefore expecting to
go from 2.4 straight to 3.0.  The recent discovery of a new strain of
the ZUC virus, however, prompted him to release an interim update to
2.5.

Unless someone has any proof to the contrary, I see no reason to
suspect that 2.5 is not a bona fide release of Disinfectant.

- -----------------------------------------------------------------------------
Mark Nutter                                                      MANUTTER@IUP
Apple Support Manager
Indiana University of Pennsylvania
G-4 Stright Hall, IUP
Indiana, PA 15705
"You can lead a horse to water, but you can't look in his mouth." - Archie B.
=============================================================================

------------------------------

Date:    03 Jul 91 13:44:53 +0000
>From:    "Brian W. Gamble" <[e-mail]>
Subject: Re: Software pricing

[e-mail] (A. Padgett Peterson) writes:

>I think I've missed something somewhere. $30/year for a single user
>Hypercard stack of virus information (a very good one though I liked
>it better as a flat ASCII file), $350/year for a soft cover anti-viral
>magazine, and people are b*tch*ng about $1500/2 years with unlimited
>updates to license software for 10 technicians to service (one would
>expect) 10,000 PCs ? $0.15/pc ? They even give telephone support! The
>answer is simple: if you don't like the price, buy something else (or
>nothing), there are plenty of alternatives.
>
>Better yet, write your own software and support it yourself, that just
>takes learning and effort.
>
>Problem is not many people today seem to have heard of John Galt or
>TANSTAAFL.

Yes Padgett, life is strange

Your society and mine both seem to think that anything needed should
be free for the asking. Any company who stands up and asks to be paid
for their efforts is going to get lots of complaints.

Actually, your postings and those from Aryeh Goretsky are clear and
useful reading. My thanks to both of you.

I would hardly call a license policy based on human nature a refusal
to sell a product. Everything I read from the McAfee group about their
license policies make a good deal of semse. They have a flexable
policy that covers everybody from the single PC owner user, right up
to a multinational company like the one I work for. You get what you
pay for people, and frankly, I think the product is worth the price.

Those who don't think the product is worth the price should quit
wasting bandwith and buy something else. It is abundantly clear that
McAfee has a product for sale, and very easy to find out what their
sales policies are for any given situation.

The only free lunch comes from friends, and even then it often isn't.

The above line(s) are mine, but may be the result of too much exposure
to a fictional character called L. Long.  TANSTAAFL makes sense to me!

- --
 Brian W. Gamble,                               [e-mail]
 NCR Canada Ltd.
 E&M Waterloo                    Charter Member -- The ShoeString Racing Team

------------------------------

Date:    03 Jul 91 09:09:00 -0500
>From:    "William Walker C60223 x4570" <[e-mail]>
Subject: IBM Write-Protection (was: Can such a virus be written ... ) (PC)

Here we go again ...

>From:    [e-mail] (Matthew F Ringel)
> Is it possible for a virus to circumvent an IBM's
> write-protection of a disk ...

NO!  If a diskette is write-protected (cover the notch, slide the
slide, whatever), the IBM floppy controller will not allow any writes
to that diskette.  Now, there have been weird failures of the write-
protect mechanism which have allowed writes (light bouncing around
because of a silver tab, light passing through a translucent disk
cover, a short in the write-protect detector, etc.).  One which I've
seen myself is an "electrical tape-like" write-protect tab which, when
used in a drive with a mechanical detector (a switch), eventually got
an indentation deep enough to let the switch engage, allowing writes
to the diskette.  In all of these cases, HARDWARE was at fault.  With
the present floppy controller system, software CANNOT bypass the
write-protect mechanism

   "...and there's no doing anything about it!"
                           -- The Rum Tum Tugger, "Cats"

Bill Walker ( [e-mail] ) |
OAO Corporation                        |
Arnold Engineering Development Center  | "I'd like to solve the puzzle, Pat"
M.S. 120                               |
Arnold Air Force Base, TN  37389-9998  |

------------------------------

Date:    01 Jul 91 16:43:00 -0500
>From:    "zmudzinski, thomas" <[e-mail]>
Subject: sideshow on doom2:reply (PC)

    While I agree with Mr. Slade on the benefits of encrypting search
strings to prevent false positives, his statement:

> As Ross [Greenburg] has pointed out, no matter how well strings are
> encrypted, eventually someone will break the code, and then it is a
> trivial matter to write a virus that circumvents that package.

should not go uncontested.  This paraphrase contains two (mathematical,
not grammatical) infinitives, "no matter how well ... encrypted" and
"eventually".  If I can play with one infinitive, let alone two, I can
probably prove the world is flat (well, it _is_, locally) or some such.
Actually, what Mr. Greenburg wrote was:

>>                                      The bad guys can certainly break
>> whatever coding scheme I use, thereby using the string list just as if
>> it were not encoded at all.

    Mr. Greenburg's statement describes his assessment of his
abilities to develop/implement a cryptographic system.  If he says
that he cannot do something he believes to be difficult, so be it --
he knows where his strengths lie.

    On one hand, if all one is trying to do is prevent false positives
from other scanners, trivial bit flipping when the program is loaded
(to avoid "finding" their images on disk) and again at EOJ (to clean
up memory) will do just fine.

    And on the other hand, does anyone _really_ believe that the "bad
guys" _don't_ run the latest crop of anti-viral software to check that
their "products" won't be caught immediately?

Tom Zmudzinski   *  *  *   ZmudzinskiT @ IMO-UVAX.DCA.MIL

#include <std/disclaimer.h> /* To keep the lawyers happy */
#include <std/cute_quote.h> /* To keep the reader happy */
#exclude <all/flames.h>     /* To keep ME happy */

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 116]
******************************************
VIRUS-L Digest   Monday,  8 Jul 1991    Volume 4 : Issue 117

Today's Topics:

Recurring 4096 Infection (PC)
VSHLD80B.ZIP - Resident virus infection prevention program (PC)
VIRX16.ZIP - VIRX v1.6: Easy to use free virus checker (PC)
VirusX (PC)
Demo Disk from Mainstay (Mac)
DOS 5.0 & FPROT116 (PC)
Virus Scanner (PC)
Re: McAfee on VSUM accuracy and Microcom (PC)
sideshow on doom2:reply (PC)
TNT AntiVirus from CARMEL / WARNING !!! (PC)
Re: Recalciterant infection with Frodo
IBM Anti-Virus Product 2.1.2 (PC)
Introduction to introductory columns (general)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    03 Jul 91 09:14:00 -0500
>From:    "William Walker C60223 x4570" <[e-mail]>
Subject: Recurring 4096 Infection (PC)

>From:    Aviel Roy-Shapira <[e-mail]>
> Help please!  I have a recalciterant infection by Frodo or 4096.  I am
> not sure about the source of the infection, but somehow it got into my
> system.  Clean (V. 77) cleaned the disk alright, but the infection
> keeps poping up.  It has become even wierder.  Both Clean, Virus Scan,
> and F-Fchk (115) report that all the files on my hard disk are free
> from the virus.  But, if I boot from the hard disk, and I run
> F-SYSCHK, it says the virus is lurking in memory.  I don't get this
> warning if I boot from a floppy.

> My config.sys file contains Device=DMDrvr.bin, Device=f-driver.sys,
> files=40 and buffers=20.  I don't run any programs or TSR from my
> autoexec, which simply states the path and sets a couple of
> environment variable.  DMDrvr.bin appears to be clean, as its length
> is 8000 bytes or so and it didnot change.

> I thought that Frodo was only a COM and EXE file infector, yet it
> somehow entered my system and refuses to leave. Any ideas?

4096 also infects COMMAND.COM and (I think) .SYS and .BIN files, but
SCAN should still find it there.  I have a few ideas to try.  Since I
don't know your level of expertise, forgive me if I say something you
already know or have already tried.

4096 is a "stealth" virus because it covers its tracks if it is active
in memory.  For this reason, you must first boot from a known clean
floppy (usually your original DOS diskette) before running SCAN or
whatever.  A potential problem that I see in your case is DMDRVR.BIN,
which (if I'm not mistaken) is Disk Manager, implying that you have a
large hard disk partitioned into several logical drives.  Booting from
a pure DOS floppy will not allow access to partitions other than C:.
One thing you can do is create a bootable floppy (after booting from a
known clean floppy, of course), copy DMDRVR.BIN from your original
Disk Manager diskette (SCAN it first), make a CONFIG.SYS file on the
floppy which contains only DEVICE=DMDRVR.BIN, and add a write-protect
tab.  Booting from this diskette should give you access to all
partitions on your hard disk as well as provide a clean environment in
which to run SCAN.

Since you apparently do not know what is still infected, try the
following.  After booting from a known clean floppy, do
     SYS C:
     COPY COMMAND.COM C:
to put a clean system back on your hard disk.  Before rebooting,
rename CONFIG.SYS and AUTOEXEC.BAT to something else (I know you said
that you have no programs in AUTOEXEC, but I'm making this more
generic).  Reboot, then SCAN the system.  If the virus is NOT in
memory, restore CONFIG.SYS, but take out the DEVICE=F-DRIVER.SYS line.
Copy the DMDRVR.BIN file from your original Disk Manager diskette to
drive C:.  Reboot and SCAN.  If the virus is still NOT in memory,
restore the line DEVICE=F-DRIVER.SYS, and copy F-DRIVER.SYS from a
known clean source if you have one.  Reboot and SCAN.  Restore
AUTOEXEC.BAT.  Reboot and SCAN.  Now start running programs and SCAN
after each program.  I know this seems like a pain-in-the-butt, time-
consuming procedure, but if the anti-virus programs aren't finding the
remaining infected files, it's about the only way.

I hope this helps in some way and hasn't duplicated your efforts.

Bill Walker ( [e-mail] ) |
OAO Corporation                        |  "I think, therefore I am.
Arnold Engineering Development Center  |      Nah, I think not."
M.S. 120                               |           *POOF*
Arnold Air Force Base, TN  37389-9998  |

------------------------------

Date:    Wed, 03 Jul 91 13:13:00 -0600
>From:    [e-mail] (McAfee Associates)
Subject: VSHLD80B.ZIP - Resident virus infection prevention program (PC)

I have uploaded to SIMTEL20:

pd1:<msdos.trojan-pro>
VSHLD80B.ZIP    Resident virus infection prevention program

     Version 80-B of VSHIELD has been released.  This version
replaces Version 80, which mis-identified some files encrypted
with ICE as being infected with the Crypt-1 virus.
     The validation results for VSHIELD Version 80-B should be:

              FILE NAME:     VSHIELD.EXE          VSHIELD1.EXE
                   SIZE:     33,723               11,281
                   DATE:     07-01-1991           02-14-1991
    FILE AUTHENTICATION
         Check Method 1:     9B2B                 6B40
         Check Method 2:     097C                 103E

Regards

Aryeh Goretsky
McAfee Associates Technical Support
- - -
McAfee Associates     | Voice [phone]    | [e-mail]
4423 Cheeney Street     | FAX   [phone]    | (Aryeh Goretsky)
Santa Clara, California     | BBS   [phone]    |
95054-0253  USA         | v.32  [phone]    | [e-mail]
ViruScan/CleanUp/VShield | HST   [phone] | (Morgan Schweers)

------------------------------

Date:    Wed, 03 Jul 91 13:25:00 -0600
>From:    [e-mail] (Ross Greenberg)
Subject: VIRX16.ZIP - VIRX v1.6: Easy to use free virus checker (PC)

I have uploaded to SIMTEL20:

pd1:<msdos.trojan-pro>
VIRX16.ZIP      VIRX v1.6: Easy to use free virus checker

VIRx is a freely distributable scanning program -- there is *no*
charge associated with it, although copyrights *are* maintained by
both Microcom and me.

In addition to SIMTEL20, it is available on CIS and on my BBS at
212-889-6438.

===
                What's New In VIRx Version 1.6

1.   VIRx Version 1.6 now detects six newly discovered viruses,
bringing the total count to just over 500.

2.   VIRx now indicates whether an infected compressed program
was infected before or after the compression (PKLITE and LZEXE).
This was trivial to implement, but a useful addition.

3.   Another few cycles were shaved off our decompression routines:
experience pays.  For those wondering, all decompression routines
are completely internal and done in memory --- and always have been.

Ross
- - -
Ross M. Greenberg <[e-mail]>
Author, Virex-PC, VIRx and FLU_SHOT+

------------------------------

Date:    03 Jul 91 17:03:58 +0000
>From:    Tom Carter <[e-mail]>
Subject: VirusX (PC)

I have asked this question before but have received nil replies.
PLEASE, can someone out there tell me what the latest version of
VirusX really is??
Thanx.....

------------------------------

Date:    Wed, 03 Jul 91 20:58:05 +0000
>From:    [e-mail] (Rob Schaeffer)
Subject: Demo Disk from Mainstay (Mac)

The demo disk from Mainstay has nVIR attached to the archive.  It
seems to not be able to spread, but it is there.

Disinfectant nicely removes the virus.

I would be curious to know why the virus doesn't spread.

Rob

- --
[e-mail]

"Putting magnets on the T.V. distorts the picture and
   makes it more real."

------------------------------

Date:    Wed, 03 Jul 91 16:44:46 -0700
>From:    Steve Clancy <[e-mail]>
Subject: DOS 5.0 & FPROT116 (PC)

A user recently posted this on our BBS.  Has anyone else experienced this?

"I was wondering if any one has experienced a problem with FPROT116.
Since I installed it with msdos ver 5.00 it hangs my system with the
message Virus Alert!! Int 13 has been changed. I have tested and no
virus is found. If I disable f-driver in my config.sys file everything
is ok. All other programs associated with this program works fine. Any
thoughts or suggestions?"

I am not familiar enough with FPROT116 or DOS 5.0 to make an
intelligent comment.  Any help will be appreciated.

- -- Steve Clancy

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
%   Steve Clancy, Biomedical Library  %  WELLSPRING RBBS              %
%   University of California, Irvine  %  714-856-7996 300-2400 24hrs  %
%   P.O. Box 19556                    %  714-856-5087 300-9600 24hrs  %
%   Irvine, CA  92713   U.S.A.        %  [e-mail]          %
%                                     %  [e-mail]             %
%.....................................................................%
%       "As long as I'm alive, I figure I'm making a profit."         %
%                                           -- John Leas, 1973        %
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

------------------------------

Date:    Thu, 04 Jul 91 09:23:14 +0700
>From:    Vincent Chan <[e-mail]>
Subject: Virus Scanner (PC)

Hi,
   I have read with interest some of the reviews and entries here in
this Virus List and I must say that this is by far the most
informative and well discussed topic on computer virus. I have also
followed some of the discussions on various virus scanner on the
market today, be it commercially available or shareware, these
discussions have helped me to choose the right product that will cater
to my need.
   Two of the virus scanners that I found most helpful for the
detection and removal of virus are Fprot from frisk and McAfee Scan.
Both of these product have helped me to detect and remove some of the
prevalent virus over here.  The most common virus is Joshi virus, that
has caused me much headache and heartache at times. Both of these
product have managed to detect and remove the virus.
    Recently I was introduced to Ross Greenberg VIRX. This program
looks interesting and it is able to scan the harddisk for virus at
considerable speed. But I have not really explored the potential of
this program. But recently I tried to scan a diskette which has been
infected with Joshi virus and it couldnt detect it! Fprot and McAfee
Scan have no problem with it.  The VIRX version is 1.5. I dunno
whether the author realised this or not.  Anyway I read from the
latest issue of Virus-l that Ross has come out with the latest version
of VIRX 1.6 and hopefully will be able to fix the problem that I
mentioned above, if not in this version then future version of Virx.

------------------------------

Date:    Sat, 29 Jun 91 00:43:49 +0000
>From:    [e-mail] (McAfee Associates)
Subject: Re: McAfee on VSUM accuracy and Microcom (PC)

[e-mail] writes:
[stuff deleted]
>
>This is good news.  I was under the impression that Microcom attempted
>to license a copy from you and was told that they may not use it
>without a license and that a license would not be issued to Microcom
>under any circumstances.
>
>I am glad that the information given to me is false and that Microcom
>is expressly being given permission to utilize this product from the
>vendor.  I would presume there is a charge for such usage: what would
>that charge be for *only* one computer to use your product? I'll be
>sure to report that amount to the Microcom people I deal with.
>
>Ross

Hello Ross,

I've given Mr. McAfee a copy of your message, but he hasn't typed up a
reply yet.  In the meantime, perhaps you could leave me your mailing
address and/or fax number so that I could give that to John for a
(faster) reply.

Thanks,

Aryeh Goretsky
McAfee Associates Technical Support
- - --
McAfee Associates     | Voice [phone]    | [e-mail]
4423 Cheeney Street     | FAX   [phone]    | (Aryeh Goretsky)
Santa Clara, California     | BBS   [phone]    |
95054-0253  USA         | v.32  [phone]    | [e-mail]
ViruScan/CleanUp/VShield | HST   [phone] | (Morgan Schweers)

------------------------------

Date:    Thu, 04 Jul 91 02:27:30
>From:    [e-mail]
Subject: sideshow on doom2:reply (PC)

>From:    "zmudzinski, thomas" <[e-mail]>
>
>Actually, what Mr. Greenburg wrote was:
                          ^
Actually, what Mr. Greenberg wrote was:
                         ^
                     minor nit... :-)

>> The bad guys can certainly break
>> whatever coding scheme I use, thereby using the string list just as if
>> it were not encoded at all.

>    Mr. Greenburg's statement describes his assessment of his
>abilities to develop/implement a cryptographic system.  If he says
>that he cannot do something he believes to be difficult, so be it --
>he knows where his strengths lie.

Whoa!  I'm sure that simply sticking in DES encryption is probably
within even my meager abilities -- provided that the instruction
manual doesn't use words that are too big...  But does even using DES
(provided I can find the on/off switch on my computer by myself)
really buy us anything?

It's just the idea that it's not that tough to break such a scheme:
recall that I spend a good deal of my life actively disasming
encrypted viruses.  Anything that is gonna be disasmed at run time is
trivial to disasm by anyone with their mind set on it.  Remember that,
regardless of the scheme used to make such a marvelous cryptographic
system, the key *must* be included in the body of the program in order
for it to work convieniently.

To have different keys that are external to a program that are
different from machine to machine would be a tech support nightmare.
Have you ever tried to figure out what shipping >50K copies of code
*really* means? I merely have to code this stuff: Microcom has to do
tech support.  I have the easy part of the job: disasming new viruses
and creating fast search algorithms is nothing compared to dealing
with Martha from BrokenHipBone, Arkansas who wants to know why she has
to stick the ignition keys to her tractor into the floppy drive door
when the machine asks her to "insert her key, then press any key."

She will, of course, end up asking wherere the "any" key is.

>    And on the other hand, does anyone _really_ believe that the "bad
>guys" _don't_ run the latest crop of anti-viral software to check that
>their "products" won't be caught immediately?

Hey, I'm sure that most of the anti-virus people probably have bad
guys as beta testers without even knowing it!

Ross

------------------------------

Date:    04 Jul 91 09:02:14 +0700
>From:    [e-mail]
Subject: TNT AntiVirus from CARMEL / WARNING !!! (PC)

This is a warning to everybody, who intends buying

    the product            Turbo Anti-Virus
    from                   CARMEL
    distributed by         EPG Softwareservice, Germany

In January 91 I bought this product (Version 7.02).  The program
itself has a nice user-interface and was at the time I bought it quite
up-to-date.  By buying the product they promise you a quarterly
update.

HAAAAAAAAAAAAAAAAAAAAAAAAAA ... well, they promise ?!?!?

I got version 7.02. It's now half a year later and I've never seen an
update.  I know from other people who bought the stuff later, that
they got meanwhile up to 7.06. During a phone call with EPG they told
me about V7.1.

Totally I sent them a FAX for customer support (something they also
promised); you expect right ... I never got an answer ...  and I
called them up three times.

I think you will agree with me that nothing needs to be more
up-to-date than Virus-protection packages.

So with my experiences I can only recommend:

                   DO NOT BUY  TNT ANTI-VIRUS

at least not from EPG Softwareservice, Germany.

You can find enough other good software, where you get updates so you
can catch up with the virus-spreaders.

bye .............................................................  Didi

------------------------------

Date:    Thu, 04 Jul 91 08:10:46 +0000
>From:    [e-mail] (McAfee Associates)
Subject: Re: Recalciterant infection with Frodo <4096> (PC)

[e-mail] (Aviel Roy-Shapira) writes:
>Help please!  I have a recalciterant infection by Frodo or 4096.  I am
>not sure about the source of the infection, but somehow it got into my
>system.  Clean (V. 77) cleaned the disk alright, but the infection
>keeps poping up.  It has become even wierder.  Both Clean, Virus Scan,
>and F-Fchk (115) report that all the files on my hard disk are free
>from the virus.  But, if I boot from the hard disk, and I run
>F-SYSCHK, it says the virus is lurking in memory.  I don't get this
>warning if I boot from a floppy.
[rest of message deleted...]

Hello Mr. Roy-Shapira,

One POSSIBLE reason the virus might be occuring is because there is a
segment of viral code stuck at the end of one of the files loaded when
your hard disk boots.  When a file is saved on disk, space is
allocated for it in clusters.  If a file does not fill up the last
cluster allocated for it, DOS will fill the left-over space with
garbage from memory to pad out the file so it fills up the cluster to
the end.  If the virus were in memory it could have been written into
the "empty" space at the end of a cluster to pad the remaining space
in the cluster.  If this occurred, whenever the file was loaded into
memory, the virus signature would appear because it was read in as
well.

The virus itself would not be infectious.  First off, it's most likely
that only a relatively small segment of code was stored at the end of
the cluster, and secondly, such viral code exists beyond the End Of
File marker; it's not recognized as being part of the program and will
not be executed.  So what you're left with is an annoying false alarm.

The best way to deal with this is to overwrite the space at the end of
cluster chains on the disk.  A practical way to do this is to
defragment the fixed disk with a disk optimizing program.  This will
usually overwrite any possible "virus garbage."

Another solution may be a program called COVERUP1.ZIP in the SIMTEL20
archives.  It says that it erases the "tails" of clusters, and
overwrite the offending section of viral code.  I have not had a
chance to try this myself, so use at your own risk.

Regards,

Aryeh Goretsky
McAfee Associates Technical Support

- --
McAfee Associates     | Voice [phone]    | [e-mail]
4423 Cheeney Street     | FAX   [phone]    | (Aryeh Goretsky)
Santa Clara, California     | BBS   [phone]    |
95054-0253  USA         | v.32  [phone]    | [e-mail]
ViruScan/CleanUp/VShield | HST   [phone] | (Morgan Schweers)

------------------------------

Date:    03 Jul 91 15:22:19 -0400
>From:    "David.M.Chess" <[e-mail]>
Subject: IBM Anti-Virus Product 2.1.2 (PC)

A new level of the IBM Anti-Virus Product now exists.  It should be
available now or shortly from IBM Marketing Reps, Branch Offices, the
Electronic Software Delivery section of IBMLINK, and on Promenade (the
PS/1 support BBSy-thing).  I'll attach the contents of the WHATIS.NEW
file.  As I said a bit ago, I'm not an Official Anything, so don't
send me your money!  *8) As before, the U.S. terms are $35 for an
original license, $10 for an upgrade (for terms outside the U.S.,
contact your country IBM).

DC

               The IBM Anti-Virus Product, Version 2.1.2
             Copyright (C) IBM Corporation 1989, 1990, 1991

The following are the highlights of the changes and enhancements made
to The IBM Anti-Virus Product since the release of Version 2.00.01:

   - Added signatures for approximately 42 viruses (refer to VIRSCAN.DOC,
     section 5.1, for more details)

   - VIRSCAN now looks for the local message file "local.msg", in the same
     directory as "virscan.exe", and if it is found, virscan displays it
     upon exit (in addition to the standard messages) when one or more
     virus signatures are found. A maximum of 10 message lines are displayed.
     This facility allows sites to tell users about local procedures that
     should be followed when viruses are encountered.

   - Added support for arbitrary-length "don't-cares".  "%N" sequences (in
     place of a pair of bytes in a signature) mean that 0 to N arbitrary
     bytes can be in the corresponding position.  'N' is a single hex digit
     from '0' to 'F'.

   - Spaces are now allowed between pairs of hex digits in VIRSCAN signatures.
     This can simplify the use of signatures from other sources.

   - VIRSCAN now respects the "boot" keyword that can be used in the third
     line of virscan signatures.  If a "boot" virus is found in a file, the
     user won't by default be warned unless the third signature line also
     contains the strings "EXE" or "COM" (or both). If the -G command line
     option is specified, then the user will be warned of boot virus
     signatures wherever they are found.

   - VIRSCAN now won't complain if it can't read the boot sector of a network
     drive, unless the '-v' option is used or the boot sector scan was
     explicitly specified with the '-b' option.

   - Added the "*" option:
     "*"    scans all local fixed drives.
     "*n"   scans all network drives.
     "*f"   scans all local fixed drives.
     "*fn"  scans all local and network drives.
     For instance, try
        virscan *
     to scan all local fixed disks.

   - Improved the speed of the memory scan.

   - Documented the -NB option.

------------------------------

Date:    Mon, 01 Jul 91 20:58:28 -0700
>From:    [e-mail] (Rob Slade)
Subject: Introduction to introductory columns (general)

INTRO1.CVP   910701
        Introduction to Computer Viral Programs Column

This file/posting/column, and the ones which will follow, are a weekly
column devoted to explaining computer viral type programs.  The
material can be roughly divided into the following topic areas:
Introduction (this file), History, Functions, Protection and
Implications.  The file names will reflect this division, beginning
with DEF, HIS, FUN, PRT or IMP, continuing with a further three letter
subcategory, as appropriate, a sequence number, and all ending with
CVP.

The format is intended to be as easy as possible for all mail systems
and terminals to handle.  Each "column" will be approximately one
typewritten page in length.

The material is intended to be "non system specific", and to be
applicable to all type of computer and operating systems.  Examples
will be given from many different computers and operating systems at
different times.  Readers will note, however, that much of the
material relates to the MS-DOS "world": IBM compatible microcomputers.
This is deliberately chosen.  The "PC" platform demonstrates the
concepts that are common to all computer systems in the clearest
manner.

I retain copyright of this material.  Anyone is free to post any of
this material on any publicly accessible electronic bulletin board or
electronic mail system which does not charge for connect time or data
transfer, provided that the files/postings are posted intact,
including my copyright notice, the filename and date at the beginning
and end and my contact addresses.  Anyone wishing to post this
material on a commercial system, or to print it in a book or
periodical, please contact me, and I'm sure we can work something out.

I am sure that the material will be archived at various servers, but
the one place that I can garantee the complete set will be available
is on the SUZY information system.  This is a commercial system, but
is accessible through a local call to a Datapac or Tymnet node for
most people in Canada and the United States.  If your local computer
store does not carry the access kit for SUZY, contact Stratford
Software at [phone].

Vancouver          Usenet:    [e-mail]
Institute for      Internet:  [e-mail]
Research into      SUZY:      INtegrity or 1123
User               Snailnet:  Canada V7K 2G6
Security           Fidonet:   1:153/915

copyright Robert M. Slade, 1991   INTRO1.CVP   910701

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 117]
******************************************
VIRUS-L Digest   Monday,  8 Jul 1991    Volume 4 : Issue 118

Today's Topics:

Disinfectant 2.5 Confusion (Mac)
Self scanning executables (pc)
GUARD - prevents h.d. infection via floppy boot (PC)
Recalciterant infection with Frodo (PC)
Virus for sale, cheap (general)
Re: Recalciterant infection with Frodo (PC)
Re: Disk Boot Failure?! (PC)
Re: Requirements for Virus Checkers (PC)
Re: Words
Re: sideshow on doom2:reply (PC)
Re: Can such a virus be written... (PC) (Amiga)
Re: Disinfectant 2.5? (Mac)
Apology; Malicious Program Definitions Revisited
Stoned virus and DIR command. (PC)
sideshow on doom2:reply (PC)
Disinfectant 2.5.1 (Mac)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Thu, 04 Jul 91 13:16:37 -0600
>From:    [e-mail] (John Norstad)
Subject: Disinfectant 2.5 Confusion (Mac)

I apologize for all the confusion regarding Disinfectant 2.5. Some
time ago, when problems appeared with Apple's Compatibility Checker, I
made the mistake of saying that "there will be no version 2.5." Then
the new ZUC C virus appeared, and I released version 2.5! I had
forgotten about the possibility of a new virus appearing before I
finished my new verison 3.0 when I made the earlier statement.

We debated naming this new 2.5 version 2.4.1 or 2.6 or something else
for just this reason. I decided that there was going to be confusion
no matter what I did, so I just named it 2.5.

John Norstad
Academic Computing and Network Services
Northwestern University
[e-mail]

------------------------------

Date:    Thu, 04 Jul 91 19:02:04 +0000
>From:    [e-mail] (Eric Vaitl)
Subject: Self scanning executables (pc)

    Just in case this may be of interest to someone, I am sending out
this little code segment. I have added a call to vscan() right at the
beginning of main() in a couple of programs. vscan() should (in
theory) be able to tell if the program has been attacked by a virus
and report it to the user.
    Let's face it, most users don't want to have to check their
systems for viruses. I think one alternative might be to have our
programs start checking themselves. This should make it quite a bit
more difficult for virus writers to cause much trouble. Also, the cost
isn't very high. This thing seems to run pretty fast, and it only adds
282 bytes to the size of the executable.
    If anyone out there has access to some viruses, I would appreciate
it if you would give me some feedback on how well this thing works.

- ------------------------ cut here ------------------------------
#include <stdio.h>
#include <stdlib.h>
/*
7-4-91 Code now works off of _psp instead of _CS, it should now work in
       all memory models but tiny and huge. Also changed nlongs to an
       unsigned long just in case a very large number of
       code segments might cause an overflow. eav
7-4-91 No longer have to compute the twos complement. I decided to subtract
       fixval from chksum instead of adding them together. eav
*/
/*
Copyright 1991 by Eric Vaitl

    This function only works as is with Turbo C and the small model.
It computes a 32 bit CRC value over the entire code segment and
compares it agaist a fixed value which is stored in the data
segment. If the code segment has been altered, the program
prints an error message and terminates.
    With the small model, the code segment is the area between CS:0000
and DS:0000. The number of thirty-two bit longs that can fit in this
area is: (_DS -_CS) << 2.
    The first time a program runs with this function, it will terminate.
The programmer must then change the value assigned to fixval to the
two's complement of the reported CRC value and recompile the program.

*/

void vscan(){
    static unsigned long fixval= 0xb93916a5l;
    unsigned long nlongs;
    unsigned long chksum = 0l;
    unsigned long far *ulfp;
    nlongs = ((unsigned long)_DS - ((unsigned long)_psp + 0x10l)) << 2l;
    ulfp = (unsigned long far *) (((unsigned long)_psp+0x10l) << 4l);
    while (nlongs--) {
        chksum += *ulfp++;
    }
    if(chksum-fixval){
        fprintf(stderr,"\nThis program has been altered.\n"
                       "Check your system for possible viruses\n"
                       "Current code checksum is 0x%lX",chksum);
        exit(5);
    }
}

------------------------------

Date:    Thu, 04 Jul 91 19:33:27 -0500
>From:    Finnegan Southey <[e-mail]>
Subject: GUARD - prevents h.d. infection via floppy boot (PC)

Y Radai writes:

>From:    Y. Radai <[e-mail]>
>
>  About half a year ago, someone asked whether there was a way of
>preventing infection of one's hard disk on cold-boot when an infected
>diskette happens to be in drive A:.  As I hinted a couple of times, I
>would soon be announcing a program to do this.  Well, it's called
>GUARD and is now available in uuencoded ZIPped form to anyone who
>requests it from me by e-mail.

     I'd really like to see a review of this product.  Perhaps, Mr Slade or
Mr. McDonald could provide another of the excellent reviews they have written.
With something this new that plays with a crucial part of my OS, I'd like some
more opinions before trying.  (Translation:  I'm not going to try it, you try
it.  Hey!  Let's get Mikey...)  I'd test it, but I don't have a spare hard
drive lying around...

- -----------------------------------------------------------------------------
 Finnegan Southey - CCS HELP DESK, University of Guelph, Ontario, CANADA
        BitNet: ACDFINN.VM.UOGUELPH.CA  CoSy: [e-mail]
            You are in a maze of twisty little passages, all alike.

------------------------------

Date:    Thu, 04 Jul 91 19:35:22 -0700
>From:    [e-mail] (Rob Slade)
Subject: Recalciterant infection with Frodo (PC)

[e-mail] (Aviel Roy-Shapira) writes:

> system.  Clean (V. 77) cleaned the disk alright, but the infection
> keeps poping up.  It has become even wierder.  Both Clean, Virus Scan,
> and F-Fchk (115) report that all the files on my hard disk are free
> from the virus.  But, if I boot from the hard disk, and I run
> F-SYSCHK, it says the virus is lurking in memory.  I don't get this
> warning if I boot from a floppy.

Frodo/4096 is a "stealth" virus, and so this behaviour is perfectly
understandable.  While the virus is in memory, it will "mask" any
infections on the disk, making it impossible for a scanner to find the
infected file.  (I don't mean to imply that DMDrvr.bin may be the
infection, but if you look at its size while the system is infected, it
will not show any change in size either.

It appears that something in your boot sequence is infected, since you
don't get the warning of an infection in memory when you boot from the
floppy.  Boot from the floppy, therefore, and *then* run FPROT.  (Of
course, if you have been running FPROT from the infected system, it may
be infected as well.  Perhaps it would be a good idea to get a clean copy
if you can.)


=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Thu, 04 Jul 91 20:18:37 -0700
>From:    [e-mail] (Rob Slade)
Subject: Virus for sale, cheap (general)

I received that following message from one of the members of INtegrity on
SUZY:

== E-Mail > > Karges, Stephen ==

  Subject: Virus Reseller

  Robert, I was on a Board (CRS) in a friends mail box and I found
  a person had uploaded a message similar to the following.

  Anyone wishing to buy Virus and source code please mail $7.00 for
  a 360k disk full or $10.00 for a 1.22mb disk full. The address to
  mail payment to was:
      West Coast Virus Centre
      101 Shady Hollow Drive
      Scarborough, Ontario
      M1V 2L9

  This type of thing frosts me. Is there anything that we can to do
  put this type of person out of business. There is in fact listed
  in the postal code book an actual residental address.

  Please forward your thoughts.

  Steve Karges
  Neutron Computers
  Kitchener, Ontario

My first thought is "A WITCH!  BURN 'ER (or him)!".

My second thought is, first make sure it's for real.  It is, of course,
quite possible that someone has posted this message as a hoax, in order
to make trouble for the residents at said address.  This can be
ascertained by anyone who lives in Scarborough, or likely by the
operators of CRS (Canada Remote Systems, a local commercial BBS in
Toronto.)

Once that is determined, the first step should be to demand that CRS
remove this account.  I would think they would be amenable, since this
message is definitely counter to their best interests, but in case they
hedge, a suggestion that the (paying) users of the system do not
appreciate this might be all that is necessary.

The name of the individual concerned should be publicized, in order to
ensure that he or she is persona non grata on all possible BBS and email
systems.

The post office and telephone company should be alerted to the use that
this person is making of their facilities, and of the fact that the
computing community objects in the strongest manner to such activities.
While the legality of such actions are open to question, "community
standards" of behaviour may apply here.

Some will question the fact that I have publicized the address here:
after all, we are quite sure that some virus authors read this list.  I
would replay, as has been suggested in the past, that they will likely
obtain this information anyway, and we have little to gain, and much to
lose, by suppressing it.

- ------

On a different subject, my recent posting regarding the two versions of
the SCANV80.ZIP file that were available from different sources was not
sufficiently clear.  It was never my intention to suggest that either
McAfee Associates or Keith Peterson were in any way at fault.  I failed
to stress the fact that I found absolutely no evidence of any problem
with either file.  Both McAfee Associates, in maintaining SCAN over the
years, and Keith, in maintaining the largest and most valuable source of
shareware that I am aware of, deserve only our thanks, and I apologize
for generating this misunderstanding.


=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    05 Jul 91 09:10:29 +0000
>From:    [e-mail] (Fridrik Skulason)
Subject: Re: Recalciterant infection with Frodo (PC)

[e-mail] (Aviel Roy-Shapira) writes:
>I thought that Frodo was only a COM and EXE file infector, yet it
>somehow entered my system and refuses to leave. Any ideas?

Two (or rather 3) possibilities.

1) The original infected program is not scanned, because it has been packed
   by LZEXE, DIET, AXE, TINYPROG, PKLITE or EXEPACK.  It is becoming ever more
   popular to distribute viruses this way - a very effective way to hide the
   first generation sample - It will not be detected by most scanners although
   later generation samples are detected normally.  Try running version 1.16
   and check if it reports any packed files.

2) The virus is active while you are running the scanner, so the infection
   is not found - this does not seem to be the case, as you described
   the circumstances.

3) The virus is present is some other file which is read and may be found in
   memory.  It is not well known, but Frodo will "infect" any file where
   the sum of the ASCII values of the file extension is 223 or 226.  In
   addition to .COM and .EXE files, this includes .OLD .MEM .PIF .QLB
   .DWG .LOG and .TBL

   This can be checked by using the /ALL switch - or /A for SCAN.

- -frisk

------------------------------

Date:    05 Jul 91 09:17:33 +0000
>From:    [e-mail] (Fridrik Skulason)
Subject: Re: Disk Boot Failure?! (PC)

[e-mail] (Greg Burlile) writes:
>Could someone please give me some input as to why this is happening.
>Is it a virus?

Might be - but without more information (such as a dump of the boot sector
and the PBR) it is hard to tell.

Anyhow, viruses can easily do something like this.  I was running one recently
(on one of my test machines) and it managed to corrupt things so thoroughly
that I was not only unable to boot from the hard disk - I was unable to boot
from a diskette unless I unplugged the hard disk first!  When the computer
had booted from a diskette I was able to plug the hard disk back in and
reformat it.

As this behaviour was rather unexpected I tried this particular virus again,
with the same result.

- -frisk

------------------------------

Date:    05 Jul 91 09:24:37 +0000
>From:    [e-mail] (Fridrik Skulason)
Subject: Re: Requirements for Virus Checkers (PC)

[e-mail] writes:
>Heck, *I* was under the impression that everybody *loved* command line
>interfaces (maybe my UNIX background showing through?) --- but it
>seems people are in love with those horrid little drop and shadow
>boxes.
>
>Guess what Version 2.0 has in it....

Don't forget the Pop-up alert messages - they are included in version 2.0
of my program, along with the shadow boxes.  :-)

But of course you can use the command-line interface if you want to - I guess
that applies to you program as well...right ?

- -frisk

------------------------------

Date:    05 Jul 91 09:27:51 +0000
>From:    [e-mail] (Fridrik Skulason)
Subject: Re: Words

[e-mail] (Johnathan Vail) writes:

> virus - a piece of code that is executed as part of another program
>     and can replicate itself in other programs.  The analogy to real
>     viruses is pertinent ("a core of nucleic acid, having the ability to
>     reproduce only inside a living cell").  Most viruses on PCs really are
>     viruses.

But, what about:

    Overwriting viruses, which destroy the programs they infect

    "Companion" viruses, such as AIDS II and TPWORM, which do not
    change the programs they "infect".

    viruses which replace the victim, and include its functionality
    (the PBR infections of Azusa are the only example I know of).

- -frisk

------------------------------

Date:    05 Jul 91 09:45:45 +0000
>From:    [e-mail] (Fridrik Skulason)
Subject: Re: sideshow on doom2:reply (PC)

My opinions on signature encryption:

I use two types of encryption in my program.  Signatures on the disk are
encrypted using a fairly simple algorithm, which would be easy to break
in a day or two by a determined hacker.  Nevertheless, I still find it
worthwhile to use this simple method.

    - Anybody trying to modify a virus so it is not detected by a scanner
      can very easily do so if the signatures are not encrypted.  By
      encrypting them (and by using two signatures per virus) I make this
      a bit more difficult.

    - It would be pointless to use a more sophisticated encryption - I could
      encrypt the signatures using DES, for example, but my scanner would
      have to include the decryption routine as well as the key, so it would
      only mean slightly longer time needed to attack the signatures - no
      real improvement in security.

    - This makes it more difficult for anybody to take my set of signatures
      and use them in a different product.  I spend considerable time selecting
      two good signatures for each virus, and I do not like anyone using
      my set of signatures in a competing product.

Signatures in memory are encrypted in a trivial way - just so I don't have to
worry about any other scanner finding them in memory after my program has run.

I believe I more-or-less agree with what Ross had to say on the subject.

- -frisk

------------------------------

Date:    05 Jul 91 08:56:53 +0000
>From:    jerry cullingford <[e-mail]>
Subject: Re: Can such a virus be written... (PC) (Amiga)

>>However, the question was
>>whether a virus-infected diskette could infect the system, when the
>>user issued a 'DIR' command.

>>The answer to that question is a definite NO - on a PC, that is - but
>>I am not sure if the same applies to the Amiga or the Mac - perhaps
>>somebody else can clarify that.

The answer is the same for the Amiga.

While a virus could infect the DIR command, and then infect write
enabled disks if you did a DIR (using the infected command), there is
no risk of BECOMING infected by using a clean DIR on an infected disk.

In order to become infected, you must execute the virus code, either
by booting off an infected disk for bootblock viruses, or by running
an already infected program.

Given a clean system, reading from an infected disk (by DIR or other
means) is safe. booting from, or executing something from, an infected
disk is where the danger lies.

+-----------------------------------------------------------------+     |
| Jerry Cullingford  #include <std.disclaimer>     [phone] |   ,-|--
| [e-mail] (was [e-mail]) or [e-mail]      x3203 |   \_|__
+-----------------------------------------------------------------+ \___/

------------------------------

Date:    Fri, 05 Jul 91 14:22:41 +0000
>From:    [e-mail] (Joshua M. Alden)
Subject: Re: Disinfectant 2.5? (Mac)

[e-mail] (Rob Slade) writes:

>What gives?

    At the time, the System 7 compatibility checker was wrong.
However, since then Disinfectant 2.5 HAS been released, despite John
Norstad's earlier claim that it wouldn't be.  He updated Disinfectant
so that it would be System 7 complete and so that it would deal with
two obscure viruses.

    So, the System 7 correction is dated, and there IS now a
Disinfectant 2.5.

- -Josh.

- --
Josh Alden, Consultant, Dartmouth Computing | #61 Hidden Lane
 Private mail: [e-mail]   | West Lebanon, NH 03784-9720
   Virus mail: [e-mail]     | [phone]

------------------------------

Date:    05 Jul 91 10:32:00 -0500
>From:    "William Walker C60223 x4570" <[e-mail]>
Subject: Apology; Malicious Program Definitions Revisited

Before I start, let me say one thing  I wrote:
> Here we go again ...
> From:    [e-mail] (Matthew F Ringel)
> > Is it possible for a virus to circumvent an IBM's
> > write-protection of a disk ...
> NO! ...
I apologize to Matthew for my hot response to his question.  While
those Virus-L readers who recently participated in (or silently
tolerated) the recent write-protect discussion may understand my
attitude, Matthew asked an innocent question, not intending to open
himself up to attack.  Sorry, Matthew.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>From:    Robert McClenon <[e-mail]>
> From:    [e-mail] (Rob Slade)
> > [e-mail] (Johnathan Vail) writes:
> > > Most viruses on PCs really are viruses.
> > If so, you will have to define "most viruses on PCs", since many
> > of the more successful PC viri are BSI's.
> Slade has a good question.  He is basically demanding clarification
> of terminology.  We need that.

In Virus-L V4 I060, Eldar A. Musaev started to clarify the terminology
by classifying malicious software by differences in function.  I
expanded on that in Virus-L V4 I071.  Tim Martin corrected some of my
terminology in Virus-L V4 I072.  Finally, postings from several people
caused me to correct my spelling of the plural of "virus."  The
correct spelling is "viri," according to the rules of spelling in the
Lincoln Library of Essential Information (my dictionary doesn't have a
plural listed for "virus").  The digested and corrected definitions
follow.  Comments, additions, and further corrections are invited.

- - --------------------
Malicious Program Definitions

The functional criteria for classifying malicious programs are:
I.   Replication
     1.  Non-replicator
         A program which does not copy itself.
     2.  Dependent Replicator
         A program which copies itself only when the host program is
         executed.
     3.  Independent Replicator
         A program that, once started (e.g. TSR), could copy itself
         continuously without outside assistance.

II.  Host Basis
     1.  Standalone (non-host-based)
         A program which does not require another program to help it
         run and/or spread.
     2.  Host-based
         a.  Spawning
             A program which leaves the host program intact, but runs
             before the host program and calls or "spawns to" it.
         b.  Overwriting
             A program which overwrites a portion of the host program
             or deletes and replaces it entirely, so that it is run
             instead of the original program.
         c.  Parasitic
             A program which attaches itself to the host program,
             leaving it functionally intact.

If the term "virus" ("viri") is used for host-based dependent
replicators, and "bacterium" (plural "bacteria") is used for host-
based independent replicators (for lack of better terms to separate
the two), the resulting classifications and associated names are:

I.   Standalone Non-replicators
       Trojan Horses            Example:  ARC 5.13
II.  Spawning Non-replicators
       Spawning Trojans
III. Overwriting Non-replicators
       Overwriting Trojans      Example:  Twelve Tricks
IV.  Parasitic Non-Replicators
       Parasitic Trojans

V.   Standalone Dependent Replicators
       Replicating Trojans      Example:  CHRISTMAS EXEC (BitNet)
VI.  Standalone Independent Replicators
       Worms                    Example:  Morris Worm (Internet)

VII. Spawning Dependent Replicators
       Spawning Viri            Example:  Aids II
VIII.Overwriting Dependent Replicators
       Overwriting Viri         Example:  382 Recovery
IX.  Parasitic Dependent Replicators
       Viri                     Example:  Vienna

X.   Spawning Independent Replicators
       Spawning Bacteria
XI.  Overwriting Independent Replicators
       Overwriting Bacteria
XII. Parasitic Independent Replicators
       Bacteria                 Example:  Jerusalem

Some of the resulting combinations don't have examples of which I'm
aware at this time, and some of those (such as a parasitic non-
replicator) are not likely.  Also, some people may say that the Lehigh
virus is an overwriting virus.  I would call it parasitic, since it is
not a complete program by itself, but attaches itself to COMMAND.COM,
even though it overwrites the stack space.
- - --------------------

Bill Walker ( [e-mail] ) |
OAO Corporation                        |
Arnold Engineering Development Center  |  AEDC -- Home of the "Chicken Gun"
M.S. 120                               |
Arnold Air Force Base, TN  37389-9998  |

------------------------------

Date:    Fri, 05 Jul 91 11:12:27 -0700
>From:    Mike Ramey <[e-mail]>
Subject: Stoned virus and DIR command. (PC)

Discovered several grad students had diskettes infected with Stoned.
Experiments confirmed that a DIR command on these diskettes caused
Stoned to become resident in RAM.  I do not know how or when Stoned
moves to the fixed-disk partition sector/boot record.
Does this pose special problems for virus hunting & removal?
- - Mike Ramey, Computer Tech., Civil Eng. Dept., U of WA, Seattle.

------------------------------

Date:    Fri, 05 Jul 91 15:03:29 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: sideshow on doom2:reply (PC)

>From:    "zmudzinski, thomas" <[e-mail]>

>    Mr. Greenburg's statement describes his assessment of his
>abilities to develop/implement a cryptographic system.  If he says
>that he cannot do something he believes to be difficult, so be it --
>he knows where his strengths lie.

This is not just Ross's opinion. His program must be able to be
publicly disseminated and be able to decrypt itself without the user
providing any sort of key. What he is doing is hiding it from casual
observation, not trying to deliver an unbreakable code (literally for
semantics buffs, encrypting not encoding), unbreakable code cannot be
produced given these ground rules so why should he try ?

>    And on the other hand, does anyone _really_ believe that the "bad
>guys" _don't_ run the latest crop of anti-viral software to check that
>their "products" won't be caught immediately?

Not a valid point. With encrypted strings, the "bad guys" still have
to either de-crypt the code to find the trigger string(s), assuming
there is one, or just keep trying variations to find one that will not
trip the scanner either as itself or as any other virus. Given
algorithmic signatures (not completely string related), this can be
much more difficult than with a simple string scanner.

This at least requires significantly more work for the "bad guys" than
if the string were available "in clear".

Besides, in the future I expect more scanners able to say "I cannot
identify this file but it sure looks/acts suspicious". The early stuff
that tried to provide such warning was just too granular and tripped
too often, this does not have to be true today.

                        Cooly,
                            Padgett

------------------------------

Date:    Sun, 07 Jul 91 19:49:10 -0600
>From:    [e-mail] (John Norstad)
Subject: Disinfectant 2.5.1 (Mac)

Disinfectant 2.5.1
==================

July 7, 1991

Disinfectant 2.5.1 is a new release of our free Macintosh anti-viral
utility.

Version 2.5.1 corrects an error in the version 2.5 INIT which caused
some programs (e.g., CompuServe Navigator) to crash on Macs using the
Motorola 68000 processor (the 512KE, Plus, SE, Classic, and Portable.)

Version 2.5.1 also corrects an error in the 2.5 program which could, at
least in theory, cause crashes or hangs during program startup or when
you try to do a scan.

We apologize to everybody for the inconvenience caused by these errors in
the 2.5 release. The errors are serious, and we strongly urge all
Disinfectant users to obtain the new version 2.5.1.

Disinfectant 2.5.1 is available now via anonymous FTP from site
ftp.acns.nwu.edu [129.105.113.52].  It will also be available soon on
sumex-aim.stanford.edu, rascal.ics.utexas.edu, comp.binaries.mac,
America Online, CompuServe, GEnie, Delphi, BIX, MacNet, Calvacom,
AppleLink, and other popular sources of free and shareware software.

Macintosh users who do not have access to electronic sources of free and
shareware software may obtain a copy of Disinfectant by sending a self-
addressed stamped envelope and an 800K floppy disk to the author at the
address given below. People outside the US may send an international
postal reply coupon instead of US stamps (available from any post
office.) Please use sturdy envelopes, preferably cardboard disk mailers.

People in Western Europe may obtain a copy of the latest version of
Disinfectant by sending a self-addressed disk mailer and an 800K floppy
disk to macclub benelux. Stamps are not required. The address is:

   macclub benelux
   Disinfectant Update
   Wirtzfeld Valley 140
   B-4761 Bullingen Belgium

John Norstad
Academic Computing and Network Services
Northwestern University
2129 Sheridan Road
Evanston, IL 60208 USA

Internet: [e-mail]
Bitnet: jln@nuacc
America Online: JNorstad
CompuServe: 76666,573
AppleLink: A0173

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 118]
******************************************
VIRUS-L Digest   Tuesday,  9 Jul 1991    Volume 4 : Issue 119

Today's Topics:

Re: Words
Re: vscan() - Virus and hack resitance (Warning!)
Virus simulations - a bad idea ? (PC)
HTSCAN15, TBSCAN28, TBSCNX29, VS910630 uploaded to SIMTEL20 (PC)
Re: Can such a virus be written .... (PC)
Re: Software pricing
Encoded strings
Re: DOS 5.0 & FPROT116 (PC)
Re: Demo Disk from Mainstay (Mac)
Re: DOS 5.0 & FPROT116 (PC)
Stoned virus and DIR command (PC)
re: Self scanning executables (pc)
re: PC Plus (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    05 Jul 91 20:33:09 +0000
>From:    [e-mail] (Johnathan Vail)
Subject: Re: Words

[e-mail] (Rob Slade) writes:

   [e-mail] (Johnathan Vail) writes:

   > virus - a piece of code that is executed as part of another program
   >     and can replicate itself in other programs.  The analogy to real
   >     viruses is pertinent ("a core of nucleic acid, having the ability to
   >     reproduce only inside a living cell").  Most viruses on PCs really are
   >     viruses.
   >
   > worm - a program that can replicate itself, usually over a network.  A
   >     worm is a complete program by itself unlike a virus which is part of
   >     another program.  Robert Morris's program, the Internet Worm, is an
   >     example of a worm although it has been mistakenly identified in the
   >     popular media as a virus.
   >     bomb.

   Question:

   Given that under these definitions boot sector infectors, "spawning"
   viri and items such as Mac's WDEF are excluded from "virus", does that
   make them all "worms"?

   If so, you will have to define "most viruses on PCs", since many of
   the more successful PC viri are BSI's.

Unless I am misunderstanding how these work I would still classify them
as viri since they "infect" already existing useful code and depend on
those programs being executed before the virus code can get an
execution thread.

I am open to suggestions on wording and mistakes I may have made.  I
plan on posting a revision soon with the comments and additions I have
 recieved.

 jv

"Imagine what it would be like if TV actually were good. It would be the end
 of everything we know."  -- Marvin Minsky
 _____
|     | Johnathan Vail | [e-mail]
|Tegra| [phone] | N1DXG@448.625-(WorldNet)
 -----  [e-mail] {...sun!sunne ..uunet}!tegra!vail

------------------------------

Date:    Sat, 06 Jul 91 07:33:03 +0000
>From:    [e-mail] (Morgan Schweers)
Subject: Re: vscan() - Virus and hack resitance (Warning!)

[e-mail] sas:
>[e-mail] (Eric Vaitl) wrote:
>}
>}    Earlier, I sent out a net posting with some code that was in
>}error. Here is the is the (hopefully) correct code. When added to your
>}own programs, I believe it will make them virus and hack resistant. Any
>}feedback would be appreciated.
>
>I hate to burst your bubble, but your code is essentially useless
>against viruses.  The only viruses it would catch are the few which
>indiscriminately clobber executables, and those are very easy to spot
>anyway (the program stops working once infected).  Most viruses attach
>themselves such that they get control first; before passing control to
>the original program, they remove any changes made to the beginning of
>the executable and then jump there.  As a result, these viruses leave an
>unmodified memory image.  To self-scan itself, a program must go out to
>disk and read the executable file, not memory.
>
>On the other hand, your function will work just fine to detect someone
>going in and modifying one or more bytes of the program's code.

Greetings,
    Thanks Ralf!  I'll say pretty much the same thing...  Plus a few
suggestions.  The code posted has *NO* effect on almost any viruses.
It will catch hacks, but if someone is playing with a debugger on your
program, they can bypass that too.

    As a *PERSONAL* recommendation (this is *NOT* an official
recommendation) I would suggest looking at the MKAWARE (aka AWARE)
program.  It looks to be a solidly useful piece of code.  As I recall,
it should be available under Simtel20...  As to *WHERE*, I don't know.
Try looking at the Index.

    (Or you could call archie and look for 'aware')

    It does a CRC check on the file that was executed.  The only
drawback to this involves Stealth viruses.  These are viruses which
hide themselves before executing your program.  These will not be
caught by *ANY* checksumming or CRCing system, nor any scanning system
unless any one of those three are run from a known clean,
write-protected system disk.  However (and thankfully) these are not
common.

    Obviously, it will not protect against BSI's (Boot Sector
Infectors) either, but those aren't necessarily dangerous to the
program you are releasing.

    As a side comment, please PLEASE note in your documentation that
your program is self-checking.  The reason for this is that the
program may come up with an alarm when a third-party validation code
is added.  Often problems like this can be headed off by warning the
user in the first place that the program checks itself.

    Furthermore, I'll point out that length-checking is not always
that good an idea.  If a file is transmitted via XMODEM or sometimes
even YMODEM, it gets padded to a length divisible by 128.  This means
that the filelength expected is no longer accurate.

    As a result, of course, full file checksums/CRCs may not work either.

    This is another reason to use archiving programs!  (These problems
never should happen with any archiving programs, since the correct
size is always stored.)

    All in all, it's good to see people taking an active interest in
protecting their programs from the development stage on.  If more
people (can you say MickySoft?  I knew you could!) took this
viewpoint, I'd be happily out of a job.  *grin*

    I love my job, but I really don't like the things which caused it
to come around.  That being viruses.

                                                  --  Morgan Schweers

P.S.  Actually, in all honesty, MicroSoft has been reasonably intelligent
    in it's self-checking on occasion.  (See MS Word.)  It's just too bad
    that it's not implemented more across the board, and it's also too bad
    that there aren't reasonably *SOLID* file protections, like most
    operating systems have.  I look towards DOS 6.0 with hope, but not
    expectations.
- --
[e-mail]   |   Morgan Schweers   |  Happiness is the planet Earth in your
[e-mail]|   These messages    |  rear view mirror.  --  Jeff Glass
Kilroy Balore    |   are not the       +--------------------------------------
Freela           |   opinion of anyone.|  I *AM* an AI.  I'm not real...

------------------------------

Date:    Sat, 06 Jul 91 13:48:08 +0000
>From:    [e-mail] (Fridrik Skulason)
Subject: Virus simulations - a bad idea ? (PC)

I recently got an E-mail message from Doren Rosenthal, the author of a
virus simulator program.  It seems he has written a program which
generates files which contain various signature strings from various
viruses.

He asked me if I would provide him with a list of the signatures I
use.  As I find his program totally useless, and capable of doing more
harm than good I refused.

My reply is included below, but I would like to hear others opinions
on virus simulators, in particular this one.

- -frisk

- ------------------------- reply to Mr. Rosenthal.

Well, I am sorry to disappoint you, but frankly I don't think your
virus simulator is a good idea at all.

Even if you included the signatures from my virus scanner, which I am
not willing to give to you, this would not guarantee that my scanner
would detect your "simulated" viruses.  At least my 'Quick' scanner
would not find any of them unless the signatures were located at the
correct location in the file, and my 'Full' scanner would report each
file as infected by a new variant.

The major reason I do not think the program is a good idea is the
total inability to handle non-signature based scanners.  Algorithmic,
and in particular hash-method scanners will not detect anything in the
files.

And in fact, I don't care if my program detects your "simulated"
viruses or not.  My scanner is designed to detect real viruses, not
simulations.

- -frisk

------------------------------

Date:    Fri, 05 Jul 91 17:21:10 +0200
>From:    [e-mail] (Jeroen Pluimers HB304 tel. 4298)
Subject: HTSCAN15, TBSCAN28, TBSCNX29, VS910630 uploaded to SIMTEL20 (PC)

I have uploaded to SIMTEL20:

pd1:<msdos.trojan-pro>
HTSCAN15.ZIP    HTScan virus scan v1.5; needs VSyymmdd.ZIP
TBSCAN28.ZIP    Thunderbyte Virus Scan 2.8; needs VSyymmdd.ZIP
TBSCNX29.ZIP    Thunderbyte XScan v2.9 TSR; needs VSyymmdd.ZIP
VS910630.ZIP    Virus Signatures for TBSCAN(X)/HTSCAN - 910630

Jeroen W. Pluimers
[e-mail]  (Sun SPARC station IPC, Sun OS 4.1.1)
[e-mail] (VAX 3400, VMS 5.4)

------------------------------

Date:    Mon, 08 Jul 91 11:37:00 +1200
>From:    "Mark Aitchison, U of Canty; Physics" <[e-mail]>
Subject: Re: Can such a virus be written .... (PC)

[e-mail] (Matthew F Ringel) writes:
> [e-mail] (Pete Lucas) writes:
>>until the virus has had a look at whats there. Of course the write-protect
>>notch/slide is 99.99% effective in my experience at preventing any
>>illicit writes; you would, of course, have write-protected any diskette
>>you put in the drive before doing the hypothetical DIR command, wouldnt
>>you?
>
> Speaking of that...
>     Is it possible for a virus to circumvent an IBM's
> write-protection of a disk (if the disk is protected in the stndard
> way of covering the notch), or is it something physical that no piece
> of software can get around?
>
 1. Remember that write-protect tabs on a diskette won't stop your computer
    getting a virus from an infected diskette,
 2. Yes, it is possible for a very special type of virus to infect your PC
    when you do a DIR command; as was mentioned before, it is only possible
    if you have ANSI.SYS loaded, and such viruses tend to be obvious - both
    in terms of what goes on the screen and unusually long delays. I doubt
    a "serious" virus writer would be any more keen to use this technique
    than writing a virus in Interactive COBOL! (There are quite a few factors
    stacked against such viruses succeeding, not the least of which is the
    high chance of tracing back the actual floppy to its source).
 3. The question of write-protection failing was thrashed out a while ago.
    In summary: yes, some drives/diskettes/tabs fail to correctly protect
    from writing. Not enough to have a virus base its existance on the
    problem, and certainly nothing to do with anything the virus can control
    (no loophole in the design, simply some photo-sensors pick up light when
    they shouldn't). I've only come across one machine like that personally,
    so you shouldn't lie awake at nights worrying. But you might like to TEST
    your machine, and perhaps test new brands of diskette when they have some
    tabs that seem significantly different to anything you've used before.
    But probably the only people that will find such precautions useful are
    those who deal with a lot of computers - e.g. a friend of mine works for
    a computer maintence company, and has found he needs to test his write
    protected diskettes regularly (because he works with MANY computers, some
    are faulty in various ways, and the impact of his diagnostics diskettes
    transferring infections to other clients is a worry, and yes, he did get
    an infection on a write-protected disk once).

Mark Aitchison.

------------------------------

Date:    Mon, 08 Jul 91 12:17:00 +1200
>From:    "Mark Aitchison, U of Canty; Physics" <[e-mail]>
Subject: Re: Software pricing

There needs to be both free and charged software; there are very good
reasons for having both...

(1) the computer-using public as a whole suffer from viruses. It would
help me if the majority of PC's had enough protection to stop or
detect the common viruses, to reduce the chances of an epidemic.
Avoiding a plague out there reduces the effort I need to make to
reasonably protect my own computer systems.  I really think there
should be good software to do this, for free (preferrably built into
the operating system). In fact there is some pretty good software
already, but of course keeping up with the latest viruses is an
expense for those who produce it, and not knowing how well it performs
against new viruses (not rare ones though) is a worry for its users.

(2) Some people will always demand higher protection than others. For
most of us, it is enough to demand that (Cost of it
happenning)*(probability) is low, but there are some cases where you
really can't stand to have any virus, and that's not just on
life-support computers, but many "serious" systems, where it is worth
paying $30 for protecting a computer.

(3) The underlying problem with SCAN that was stated by an earlier
poster was that universities (for example) must obtain a site license,
i.e. pay for ALL machines to have the software, when the majority of
PC users will be in the first category, and only a minority in the
second. That's a separate question to "Is $xx per PC good value?".

(4) There should be a free database of virus information, available to
all users (and a-v writers), and it should try to standardise on
naming, etc. But whoever compiles it need not put the time into
analysing the viruses. I know this can take a lot of time and
therefore deserves financial returns. Instead, people could contribute
analyses, listings, etc to supplement the summary - in whatever form
they think will sell. Having a non-commercial, complete virus library
and free summary/identification system would help everybody; having a
compatible set of useful information (e.g. how to disinfect!) would be
worth money to many people, and that is where, to be fair, the
charging should come in.

Mark Aitchison.

------------------------------

Date:    Mon, 08 Jul 91 06:30:06 -0700
>From:    [e-mail]
Subject: Encoded strings

[From:    "zmudzinski, thomas" <[e-mail]]
>>  > As Ross [Greenburg] has pointed out, no matter how well strings are
> encrypted, eventually someone will break the code, and then it is a
> trivial matter to write a virus that circumvents that package.

should not go uncontested.  This paraphrase contains two (mathematical,
not grammatical) infinitives, "no matter how well ... encrypted" and
"eventually".  If I can play with one infinitive, let alone two, I can
probably prove the world is flat (well, it _is_, locally) or some such.
- -=-=

Of course . But, one point I implied but did not specificly state, is being
passed over altogether, here. That being:

That while most people who are writing Virus prevention/removal
routines are expirenced programmers, we make a large mistake when we
assume that the idiots are quite so expirienced. I would venture a
guess that a goodly portion of the virus idiots (The bad guys) would
be thwarted by any encryption above the trivial level.

You see, while I agree with Ross that :
>>   The bad guys can certainly break
>> whatever coding scheme I use, thereby using the string list just as if
>> it were not encoded at all.

.....I would submit that many of the different strains we've been
seeing are bad copies of the original code, often times being a simple
string change that one could have invoked using a disk editor, right
on the EXE or COM file, without ever seeing the source code.... thus
furthering the idea that much of what we see in the way of virus
programming (as opposed to anti-virus programming) is created by less
than expirienced programmers.  Ouch! Run on sentences were my problem
all through school, too. Anyway, such people would be thwarted by
encryption out of hand, thus significantly reducing the amount of
viral strains in the wild.

Standard disclaimers apply.

------------------------------

Date:    Mon, 08 Jul 91 12:40:00 -0400
>From:    "Ignorance HATES Knowledge..........!!" <[e-mail]>
Subject: Re: DOS 5.0 & FPROT116 (PC)

>A user recently posted this on our BBS.  Has anyone else experienced this?
>
>"I was wondering if any one has experienced a problem with FPROT116.
>Since I installed it with msdos ver 5.00 it hangs my system with the
>message Virus Alert!! Int 13 has been changed. I have tested and no
>virus is found. If I disable f-driver in my config.sys file everything
>is ok. All other programs associated with this program works fine. Any
>thoughts or suggestions?"
>
>I am not familiar enough with FPROT116 or DOS 5.0 to make an
>intelligent comment.  Any help will be appreciated.
>
>- -- Steve Clancy

Without getting into all the reasons why this was a problem.... The
way to fix it for me anyway... Was to boot from a floppy -- then erase
ALL the files the the SUBDIR -- \F-prot ......  I put them back from a
fresh disk then rebooted from the hard disk. Worked just fine.....

tell your user not to use the command LOADHIGH with the F-* TSRs as
it'll hang the system. The device driver will work fine with the
DEVICEHIGH command in the config.sys.

Sorry this is short, I'm sure someone else will provide a description as
to why this occurs -- I just wanted to get you an answer....

Bob Martin -- Eastern KY U. -- Academic Computing -- 606 622-1995
bitnet: Acsmartin@eku  or   graphics @eku

------------------------------

Date:    Mon, 08 Jul 91 12:01:30 +0800
>From:    [e-mail]
Subject: Re: Demo Disk from Mainstay (Mac)

>Date:    Wed, 03 Jul 91 20:58:05 +0000
>From:    [e-mail] (Rob Schaeffer)
>Subject: Demo Disk from Mainstay (Mac)
>
>The demo disk from Mainstay has nVIR attached to the archive.  It
>seems to not be able to spread, but it is there.
>
>Disinfectant nicely removes the virus.
>
>I would be curious to know why the virus doesn't spread.

It could be that it is only an nVIR stem, put there to prevent nVIR from
actually infecting the file.  It could also be the remnant of an incomplete
removal.
                                     <->
Bruce Carter, Courseware Development Coordinator      [e-mail]
Boise State University, Boise, ID  83725              [e-mail]
(This message contains personal opinions only)        [phone]@phone

------------------------------

Date:    08 Jul 91 13:19:11 +0000
>From:    [e-mail] (Ing. Alfredo Delgado Garza)
Subject: Re: DOS 5.0 & FPROT116 (PC)

[e-mail] (Steve Clancy) writes:

   A user recently posted this on our BBS.  Has anyone else experienced this?

   "I was wondering if any one has experienced a problem with FPROT116.
   Since I installed it with msdos ver 5.00 it hangs my system with the
   message Virus Alert!! Int 13 has been changed. I have tested and no
   virus is found. If I disable f-driver in my config.sys file everything
   is ok. All other programs associated with this program works fine. Any
   thoughts or suggestions?"

   I am not familiar enough with FPROT116 or DOS 5.0 to make an

I had the same troubles, i fixed it by puting the device=f-driver.sys
as the last line in my config.sys.

It looks like the SMARTDRVR.SYS takes the int 13 causing that message.

Alfredo Delgado.

------------------------------

Date:    08 Jul 91 14:51:00 -0500
>From:    "William Walker C60223 x4570" <[e-mail]>
Subject: Stoned virus and DIR command (PC)

1From:    Mike Ramey <[e-mail]>
> Discovered several grad students had diskettes infected with Stoned.
> Experiments confirmed that a DIR command on these diskettes caused
> Stoned to become resident in RAM.  I do not know how or when Stoned
> moves to the fixed-disk partition sector/boot record.

IMHO, Stoned was already resident in RAM before executing the DIR
command.  I ran the following test using a clean hard drive and a
Stoned-infected diskette in drive A:

     SCAN C: /M
          "No viruses found."
     DIR A:
     SCAN C: /M
          "No viruses found."

However, the following WILL put Stoned in memory (though not really
active):

     SCAN C: /M
          "No viruses found."
     DISKCOPY A: A:
     SCAN C: /M
          "Found Stoned Related Virus [Stoned] active in memory."

So will this:

     SCAN C: /M
          "No viruses found."
     NU A:
          [Norton Utilities 4.51 - look at boot sector, then exit by
           pressing F10]
     SCAN C: /M
          "Found Stoned Related Virus [Stoned] active in memory."

This is due to the same problem with MS-DOS which caused the PRODIGY
scare and the abuse which was recently heaped upon Ross GreenbErg:
MS-DOS does not clear resources (memory or disk) before reusing them.
If you want it done, you've got to do it yourself.  However, as
indicated by the first test, DIR does not load the boot sector into
memory in the first place.  I would be interested in seeing your
results with a SCAN /M (or equivalent), DIR, SCAN /M sequence of
tests.

One interesting note:  In an attempt to make a "defanged" version of
Stoned (with which to train users in using antivirus software), I
changed some disk write commands to disk resets and one CALL to NOP's,
and got this:
     SCAN A: /M
          "Found Azusa Virus [Azusa] in boot sector."
Are they really that close?

Bill Walker ( [e-mail] ) |
OAO Corporation                        |     "That's not a bug,
Arnold Engineering Development Center  |      that's a feature!"
M.S. 120                               |          - Anonymous
Arnold Air Force Base, TN  37389-9998  |

------------------------------

Date:    08 Jul 91 16:17:14 -0400
>From:    "David.M.Chess" <[e-mail]>
Subject: re: Self scanning executables (pc)

As I'm sure hordes of other folks will point out, Eric Vaitl's nice
little self-checker does *not* compute a CRC (as the comments say),
but only a simple add-em-up checksum.  A CRC (Cyclic Redundancy Check)
is somewhat more complex than than, no?

Also, checking the memory image of the program isn't really the right
defense against viruses; most viruses restore the memory image to
normal before passing control to the infected program, so I think
programs incorporating this method will not actually notice the
typical virus infection.  (Although I'm not entirely positive how
Turbo C does memory allocation, so I may be missing something there.)

Self-checks need to check the on-disk copy of the executable, not the
in-memory copy (and of course even then they are subject to fooling if
there's a stealth virus around).

A nice effort, though, and such idea-sharing is certainly a Good Thing!

DC

------------------------------

Date:    Mon, 08 Jul 91 19:49:52 +0100
>From:    [e-mail]
Subject: re: PC Plus (PC)

I feel the need to respond to James Nash's advert for PC Plus, as none
of the British magazines have yet shown themselves reliable in
providing objective reviews of anti-virus software.  I had hopes that
Personal Computer World might have been able to produce something, but
these disappeared when most of their best contributors left during the
management/ journalist union dispute of December 1989.

Most of the reviews I have seen have suffered from undisclosed interests.

Several considerations may have influenced Mark Hamilton's review in
PC PLUS:
*   journalists don't generally maintain their own libraries of viruses for
    testing, in this case the 100% detection rate of Bates Associates
    product indicates that Jim Bates' virus collection was used.
*   Hamilton writes for the Virus Bulletin; this publication is owned
    by Sophos.
*   RG Software has just been announced as the new distributor for the
    Virus Bulletin in the USA.
*   Microcom's Virex-PC is the commercial version of Flushot+, in one
    edition that I saw the documentation included an acknowledgement from
    the author of code contributed by Mark Hamilton.

I am not suggesting that Mark Hamilton has deliberately misrepresented
the products of these companies, but that these relationships should be
kept in mind when reading the review.

One error of fact is that Sophos's Sweep isn't "the only [anti-virus]
product in this country to have been granted a UKL1 certificate by the
Government's Computer and Electronic Security Group".  PC Security's
Eliminator gained UKL1 certification earlier this year, as reported in
Virus Bulletin January 1991.

Declaration of interests: I work at Thecia System Ltd, we produce an
anti-virus product called Virus Clean, which was not invited for inclusion
in Hamilton's review.

Thanks for your time,
Anthony Naggs

(Reply to: [e-mail] or phone me at Thecia Systems: 0273 623500)

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 119]
******************************************
VIRUS-L Digest   Tuesday,  9 Jul 1991    Volume 4 : Issue 120

Today's Topics:

New Scanner! (well, not really) (PC)
Input sought on security course
Problem with GUARD (PC)
Re: DOS 5.0 & FPROT116 (PC)
Re: TNT AntiVirus from CARMEL / WARNING !!! (PC)
Re: Self scanning executables (PC)
Re: Stoned virus and DIR command. (PC)
Virus protection reviews needed (PC)
Re: Stoned virus and DIR command. (PC)
Re: Stoned virus and DIR command (PC)
Re: Recalciterant 4096 virus (PC)
General definition - part 2 (general)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Tue, 25 Jun 91 17:57:05 -0700
>From:    [e-mail] (Rob Slade)
Subject: New Scanner! (well, not really) (PC)

I don't think I'm going to be doing a review on this one ...

A recent posting from one of the local boards ...

RW>         One more thing.  Is anyone there been in Antics?  If
RW> you do and you've seen their virus protection files then
RW> have you heard of a file called PARASCAN.ZIP.  I got it and
RW> it kept saying things like "VIRUS FOUND: THE ZSA ZSA GABOR
RW> VIRUS ... or some other famous person.  It then goes
RW> FIGHTING VIRUS...  OH NO IT IS A TOUGH BATTLE...  Almost
RW> like a cartoon if you ask me.  Well I just want to make sure
RW> it is a fake because I did download it and I erased it.

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Mon, 08 Jul 91 22:00:25 +0000
>From:    moncol![e-mail]
Subject: Input sought on security course

  I am preparing to write a paper for a graduate computer secrity
course, and would appreciate input on the following:
  I will be comparing the effects (not structure or design) of compter
virses and biological viruses.  I have seen in the literature
references to how computer viruses spread at a (typically) exponential
rate.  This is without any numbers to back it up.  Viruses affecting
people have various distributions, eg. exponential, uniform, etc...
If anyone has information on this, or can describe an accurate
accounting of where, when, and how many machines were hit and how an
attack ran over time of a computer virus, I would find it most
helpful.  Part of my paper will regard factors which affect the rate
of spread of viral programs.
  If you know of any journal with a well-documented case, or similiar
articles, I would find that helpful.  Also, a while back, I believe
Computers & Security ran an issue which included information on the
mathematical modeling of viruses or at least certain aspects.  Did
anybody (or any of you) read it?

Thank you
  Sam Nitzberg

------------------------------

Date:    Mon, 08 Jul 91 21:30:17 -0600
>From:    [e-mail] (Tim Martin; FSO; Soil Sciences)
Subject: Problem with GUARD (PC)

   I received GUARD from Y. Radai today.  I think I found a
significant problem with it.  On rebooting from the hard drive, after
an infection by "stoned", Guard removes stoned from the PBR but not
from memory.  The Int 13 vector is still routed through stoned.
FPROT's "f-mmap" shows a 2k block of memory taken from the top of
memory.  Debug shows this to be the stoned virus.  If this area is
overwritten, the system will crash on the next disk read or write.  If
instead a floppy disk is formatted, chances are it will be infected
with the stoned virus.  On the next bootup from the C drive, the virus
is gone from memory.  I haven't tried this behavior yet with other
viruses.

The experiment:
1. Install "guard", as described in the documentation.
2. Reboot the computer from a "stoned" floppy.  (Cold or warm reboot:
doesn't matter.)
3. Reboot the computer from the Hard Drive.  (Cold or warm boot, doesn't
matter.)
4. CHKDSK will show 2k missing from total memory.
5. On a 640K computer, the DEBUG command "d9f80:0000 1ff" will show the
virus at TOM.
6. At this point I formatted a 360k floppy.  It became infected.
7. Using debug to overwrite the virus area at 9f80:0000-1ff caused a
system crash on the next disk read or write.
8. Reboot from C:.  The virus is no longer in memory.  (This is because
it is no longer in the PBR.

Comments:
In my opinion, "Guard" doesn't give us anything that is not already in
Padgett's DiskSecure package.

When it is infected by a stealth virus (at least by the Empire family
of viruses) guard does not permit the computer to be rebooted from the
hard drive, and automatically remove the virus from the hard disk. (I
had expected, from the promises Mr. Radai has been making.)  One must
boot from a clean floppy and run guard from the floppy to clean the
hard drive.  I think Padgett has been right all along: you cannot keep
an MBR from being infected by a cold boot from a floppy, using
software alone.  The best you can do is immediately recognize the
infection, on rebooting from the hard drive, and then manually clean
the system after re-booting from a floppy.

Even without the error described above, Guard gives less protection
than DiskSecure. Guard does not itself use stealth to protect the MBR
from reads or writes.


     Tim Martin
     Soil Science
     University of Alberta.
***  These are my opinions: my boss has none. ***

------------------------------

Date:    09 Jul 91 08:41:38 +0000
>From:    [e-mail] (Fridrik Skulason)
Subject: Re: DOS 5.0 & FPROT116 (PC)

[e-mail] (Steve Clancy) writes:
>A user recently posted this on our BBS.  Has anyone else experienced this?
>
>"I was wondering if any one has experienced a problem with FPROT116.
>Since I installed it with msdos ver 5.00 it hangs my system with the
>message Virus Alert!! Int 13 has been changed.

I have heard of this problem, but am not sure what the cause is, as I
do not yet have DOS 5.0 A fix will be provided as soon as possible.

One person reported this problem went away if he used DEVICEHIGH=
instead of DEVICE=

- -frisk

Fridrik Skulason                 Technical Editor of the Virus Bulletin (UK)
(author of F-PROT)               E-Mail: [e-mail]    Fax: [phone]

------------------------------

Date:    09 Jul 91 08:49:00 +0000
>From:    [e-mail] (Fridrik Skulason)
Subject: Re: TNT AntiVirus from CARMEL / WARNING !!! (PC)

[e-mail] writes:
>This is a warning to everybody, who intends buying
>
>    the product            Turbo Anti-Virus
>    from                   CARMEL
>    distributed by         EPG Softwareservice, Germany
>
>I got version 7.02. It's now half a year later and I've never seen an
>update.  I know from other people who bought the stuff later, that
>they got meanwhile up to 7.06. During a phone call with EPG they told
>me about V7.1.

Well - keep in mind that this program has now been repackaged as the
'Central Point Anti-Virus'.  I don't know the terms of the contract,
of course, but I would not be too surprised if Turbo Anti-Virus would
be discontinued soon.

Of course, this is pure speculation form a not-entirely-unbiased
source, so don't take me too seriously ..... :-)

 -frisk

------------------------------

Date:    09 Jul 91 08:54:00 +0000
>From:    [e-mail] (Fridrik Skulason)
Subject: Re: Self scanning executables (PC)

[e-mail] (Eric Vaitl) writes:
>    Just in case this may be of interest to someone, I am sending out
>this little code segment. I have added a call to vscan() right at the
>beginning of main() in a couple of programs. vscan() should (in
>theory) be able to tell if the program has been attacked by a virus
>and report it to the user.

It works - 95% of the time.

It is unable to catch two groups of viruses - overwriting/destuctive
viruses such as Burger, and sophisticated "stealth" viruses such as
Frodo.

Overwriting viruses are not a problem - but detecting infection by
stealth viruses when they are active is more difficult - although not
impossible.

- -frisk

------------------------------

Date:    09 Jul 91 09:00:56 +0000
>From:    [e-mail] (Fridrik Skulason)
Subject: Re: Stoned virus and DIR command. (PC)

[e-mail] (Mike Ramey) writes:
>Discovered several grad students had diskettes infected with Stoned.
>Experiments confirmed that a DIR command on these diskettes caused
>Stoned to become resident in RAM.

NO - NO - NO

This is not correct.  Even if a 'Stoned' signature is found in memory
after you do a 'DIR' on an infected diskette, it does not mean that
the virus is installed or active.

The reason is very simple - when you do a DIR, DOS may read the boot
sector, as it contains information on the structure of the diskette.
The boot sector is simply found in one of the disk buffers - it is not
executed or active in any way.

Therefore - no problem.

- -frisk

Fridrik Skulason                 Technical Editor of the Virus Bulletin (UK)
(author of F-PROT)               E-Mail: [e-mail]    Fax: [phone]

------------------------------

Date:    Tue, 09 Jul 91 13:00:57 +0000
>From:    [e-mail] (Bill Hanrahan)
Subject: Virus protection reviews needed (PC)

Hi folks,

Does anyone know where I can get software reviews, published or not,
of f-prot, McAfee's viruscan or IBM's virscan? The July issue of PC
WORLD doesn't mention any of these and I'm required to provide some
sort of "official" comparison documentation before purchasing
anything.

Thanks for any help you can provide.

[Ed. There are two sets of independent reviews (one by Rob Slade and
the other by Chris McDonald) available by anonymous FTP on
cert.sei.cmu.edu (*NEW* IP number is 192.88.209.5) in the
pub/virus-l/docs/reviews directory.]

======================================================================
bill hanrahan                      [e-mail]
SUNY Binghamton                    [e-mail]

------------------------------

Date:    Mon, 08 Jul 91 23:41:57 +0000
>From:    [e-mail] (Andrew Turner)
Subject: Re: Stoned virus and DIR command. (PC)

[e-mail] (Mike Ramey) writes:
>Discovered several grad students had diskettes infected with Stoned.
>Experiments confirmed that a DIR command on these diskettes caused
>Stoned to become resident in RAM.  I do not know how or when Stoned
>moves to the fixed-disk partition sector/boot record.

NO NO NO!! Doing a DIR on an infected floppy cannot and will not cause
the Stoned virus to either infect the hard disk NOR go memory
resident.  The only way for the Stoned virus to go memory resident is
to boot off an infected floppy - even if it is a 'non-bootable'
floppy(All formatted floppies have a valid boot sector - a bootable
floppy also has the two hidden system files and command.com).

Once this has happened then the Stoned virus has gone resident and has
also infected the partition table on the hard disk. Any subsequent
boots off the hard disk will send Stoned memory resident - after all
the hard disk is now infected.

Note that the stoned virus can be classed as a stealth virus as it
hides itself - it was released before the 'stealth' definition was
invented.

Once Stoned is memory resident accesses of subsequent uninfected
floppies will cause the Stoned virus to infect the subject floppies -
I believe a DIR command will do this. NB!!!! The virus must already be
memory resident and the infection goes to the floppy - not the other
way!!.

Your situation sound as if your hard disk is already infected.  The
ONLY safe way to confirm this and to remove the Stoned virus is to
boot off a CLEAN and write protected floppy and THEN run the
anti-viral software to detect and remove the virus.

To be specific the Stoned virus infects your hard disk the moment the
boot sequence access the boot sector of an infected floppy. This
happens very early and before the systems files are loaded.  Suffice
to say that if you boot with an infected floppy in Drive A: then as
soon as the boot sequence accesses the floppy, the drive light comes
on, then its too late - you've been zapped.  Once on an hard disk it
resides in the partition table. The partition table, along with
storing the hard disk partition info, also has executable code that
hands control of the boot to the hard disk boot sector. It is the
partition table executable code that the Stoned virus invades.

>Does this pose special problems for virus hunting & removal?
>- - Mike Ramey, Computer Tech., Civil Eng. Dept., U of WA, Seattle.

- --
 Andrew Turner  [e-mail]
    Die, v:    To stop sinning suddenly.
            -- Elbert Hubbard

------------------------------

Date:    09 Jul 91 12:05:00 -0500
>From:    "William Walker C60223 x4570" <[e-mail]>
Subject: Re: Stoned virus and DIR command (PC)

OOPS.  In my reply to Mike Ramey concerning putting Stoned into memory
merely by doing DIR, I listed several simple tests.  One of them was:
>      SCAN C: /M
>           "No viruses found."
>      DISKCOPY A: B:
>      SCAN C: /M
>           "Found Stoned Related Virus [Stoned] active in memory."

Well, here's my mistake.  Some time before writing the reply I had
actually done this sequence, getting the above results.  HOWEVER, I
had run DISKCOPY from within another program, then ran SCAN after
exiting the program.  As a result, SCAN did not overwrite the copy of
Stoned in memory.  If DISKCOPY and SCAN are run back-to-back, SCAN
will overwrite part of DISKCOPY's data space, producing these results:

     SCAN C: /M
          "No viruses found."
     DISKCOPY A: B:
     SCAN C: /M
          "No viruses found."

Just for consistency's sake, I retried the DIR and NU tests both from
the DOS prompt and from within a program.  All results were as written
before.

No doubt there are several comments about this mistake already on
their way as I write this.  I'm just letting those who caught it know
that I'm aware of it, and those who did not catch it understand it.

Bill Walker ( [e-mail] ) |
OAO Corporation                        | "Non sequitur -- your facts are
Arnold Engineering Development Center  |  un-coordinated."
M.S. 120                               |           -- NOMAD
Arnold Air Force Base, TN  37389-9998  |

------------------------------

Date:    Tue, 09 Jul 91 21:04:20 +0700
>From:    Aviel Roy-Shapira <[e-mail]>
Subject: Re: Recalciterant 4096 virus (PC)

I want to thank everyone who sent me advice and ideas.  Padgett
Patersen and Fridrik Skulson gave the best advice. It turned out that
I had two problems, both of which were identified correctly by
Fridrik.  A few data files were infected by the virus, and the virus
was hidden in a LZE compressed file /files.  The compressed files were
part of a commercial anti virus package popular in Israel.

The first is supposed to immunize the computer and is a TSR, the
second scans a nd cleans.  When the program detects a TSR virus it can
de-activate it and proceed to clean the disk.  Would would happen, I
think, is the program would load, run the virus, and immediately
deactivate it. The signature probably remained in memory, and was
subsequently detected by other scanners.

When the TSR protecting program was run, it simply activated the virus.

Thanks again every one.
Aviel

------------------------------

Date:    Sun, 07 Jul 91 18:48:51 -0700
>From:    [e-mail] (Rob Slade)
Subject: General definition - part 2 (general)

DEFGEN2.CVP   910707
                       What and What Not
Having established that viral programs copy themselves, and
before going on to related types of programs, let me list a few
things that viri are *not*.

Let me first say that computer viral programs are not a
"natural" occurence.  These are programs which are written by
programmers.  They did not just appear through some kind of
electronic evolution.  Viral programs are written, deliberately,
by people.  (Having studied the beasts almost from their
inception, I was rather startled when a young, intelligent, well
educated executive proposed to me that viri had somehow "just
grown" like their biological counterparts.)

The popular press has recently started to publicize the term
computer virus, but without giving any details other than the
fact that viri are to be feared.  (Often the reports talk about
"main storage destroyed" and other such phrases which have very
little meaning.)  This has given most people the impression that
anything that goes wrong with a computer is a virus.  From
hardware failures to errors in use, everything is blamed on a
virus.  *A VIRUS IS NOT JUST ANY DAMAGING CONDITION.*

Likewise, it is now considered that any program that may do
damage to your data or your access to computing resources is a
virus.  We will speak further about trojan horse programs, logic
bombs and worms, but it is important to note that viral programs
have common characteristics that other damaging or security
breaking programs may lack.  Viri are not just any damaging
program.

Indeed, viral programs are not always damaging, at least not in
the sense of being deliberately designed to erase data or
disrupt operations.  Most viral programs seem to have designed
to be a kind of electronic graffiti: intended to make the
writer's mark in the world, if not his or her name.  In some
cases a name is displayed, on occasion an address, phone number,
company name or political party (and in one case, a ham radio
license number.)

On the other hand, viral programs cannot be considered a joke.
Often they may have been written as a prank, but even those
which have been written so as not to do any damage have had
bugs, in common with any poorly written program.  The author of
Stoned abviously knew nothing of high density floppies or RLL
drive specifications.  In fact, it appears that the trashing of
data by the Ogre/Disk Killer virus, one of the most damaging,
was originally intended to be reversible, were it not for an
error on the part of the programmer.  Any program which makes
changes to the computer system that are unknown to the operator
can cause trouble, the more so when they are designed to keep
spreading those changes to more and more systems.

However, it is going to far to say, as some have, that the very
existence of viral programs, and the fact that both viral
strains and numbers of individual infections are growing, means
that computers are finished.  At the present time, the general
public is not well informed about the virus threat, and so more
copies of viri are being produced than are being destroyed.  As
people become aware of the danger, this will change.

copyright 1991, Robert M. Slade   DEFGEN2.CVP   910707


=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 120]
******************************************

VIRUS-L Digest   Wednesday, 10 Jul 1991    Volume 4 : Issue 121

Today's Topics:

Re: DOS 5.0 & FPROT116 (PC)
Stoned virus (PC)
Re: Self scanning executables (PC)
F-Prot on BBS. (PC)
Doodle Virus (pc)
T.S.R's ( Which is the best )
Keypress Virus (PC)
Re: Problem with GUARD (PC)
Re: Apology; Malicious Programs Definitions Revisited
Self testing; New viruses; Beta testing; Translations (PC)
re: Research
Virus Bulletin Conference

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    09 Jul 91 19:26:38 +0000
From:    [e-mail] (Shaun Case)
Subject: Re: DOS 5.0 & FPROT116 (PC)

[e-mail] (Steve Clancy) writes:
>A user recently posted this on our BBS.  Has anyone else experienced this?
>
>"I was wondering if any one has experienced a problem with FPROT116.
>Since I installed it with msdos ver 5.00 it hangs my system with the
>message Virus Alert!! Int 13 has been changed. I have tested and no
>virus is found. If I disable f-driver in my config.sys file everything
>is ok. All other programs associated with this program works fine. Any
>thoughts or suggestions?"

I recently installed DOS 5.0 on a 25 mhz 486. When I attempted to
install FPROT116 on the system, I got the exact same result you
describe above.

Shaun.

- --
[e-mail]
- -- 100,000, perhaps 200,000 or more Iraqis died in a "Turkey Shoot"
   inappropriately called a "war."  -- Michael Albert
The above work is in the public domain, unless it is a piece of email.

------------------------------

Date:    Tue, 09 Jul 91 20:45:42 +0000
From:    [e-mail] (Strahd Von Zarovich)
Subject: Stoned virus (PC)

Hello all you Virus Gurus.

The ever friendly Stoned Virus just hit our office and luckily (???)
there was only one casualty.  It seemed to wipe out the partition
table and both copies of the fat.  I used Norton to get back the
partition table but it seems to be choking a little getting the FAT's
back.

Any Ideas?  I really hate to let it wipe out files that it doesn't think
are repairable.

Oh yeah, did I forget to mention that this was my Boss's Computer?

Thanks for ANY help.  A post or e-mail are fine either way.


- --
Do you crave power? Hate the living? Then don't be afraid of the Mists!
            Come to Ravenloft!  Your New Island Home!

Jeff Kenward: [e-mail]

------------------------------

Date:    Tue, 09 Jul 91 19:04:10 -0400
From:    Jeff Boyd <[e-mail]>
Subject: Re: Self scanning executables (PC)

A friend of mine solved the self-scanning problem, and his solution
(with TC and TP code) is in the public domain. A *true* CRC is
calculated.

Such a routine must solve a set of equations which predict what the
CRC will be after that same CRC is stored within the program itself.
Since the CRC is stored somewhere within, it is theoretically possible
for the self-check to be cracked. However, the current estimate of
time required for this is 3-4 hours on a 33-386 ... too long for such
action to escape your notice.

If there is interest in this item, let me know. I'll contact the
author and ask if he can make it available for FTP somewhere.

jeff

------------------------------

Date:    Tue, 09 Jul 91 19:53:08 -0400
From:    [e-mail]
Subject: F-Prot on BBS. (PC)

Does anyone on this list know of a public BBS that usually has the
most recent F-PROT? I will be closing my university Internet account
in a few weeks and would like to be able to access new versions as
they are released. Does Frisk offer a mail update service to
registered users?
     Thanks for any responses. You can E-mail me direct if you wish.

Mark Stoffan
University of Southern Maine
IP85272@PORTLAND           (BITNET)
[e-mail] (Internet)

------------------------------

Date:    Sat, 10 Jul 91 08:44:24
From:    "MUSTAFA T. ALGHAZAL" <[e-mail]>
Subject: Doodle Virus (pc)

Hello ,
 one of our PCs here is inficted by doodle virus .We remove it by Macafee
 clean software ,but it returned back.
 Can anybody send me some info about it,and a way to remove it .
 Thanks a lot ....

   Mustafa

____________________________________________________________________
|  MUSTAFA T. AL-GHAZAL          ||     [e-mail]    |
|  ACADEMIC COMPUTING SERVICES   ||     VOICE: (966) 3-580-0219    |
|  KING FAISAL UNIVERSITY        ||     COMPUTER CENTER            |
|  HOFUF-SAUDI ARABIA            ||     P.O.BOX 380                |
|________________________________||________________________________|

------------------------------

Date:    Wed, 10 Jul 91 08:10:48 +0000
From:    "Alan Jones" <[e-mail]>
Subject: T.S.R's ( Which is the best )

Alan J Jones
Manchester Computing Centre
University of Manchester
Oxford Road
M13 9PL
England

tele 061-275-6038
fax  [phone]


Does anyone have any feelings on what T.S.R. virus checker for the PC
gives the best protection whilst not using a vast amount of memory.

I work at the Universtiy of Manchester and on site there are about
4000 + computers and all will need some form of protection from the
students ( sorrey I ment viruses ) at this moment the little cherubs
are off on holiday ( peace, quiet, joy and bliss ).

My task is to place some form of protection on the computers before
the hoards get back and start to infect ( sorrey again I ment to say
use ) the computers and in doing so make my life a liveing hell.

The products that I have looked at so far are :-
Dr Solomons                Virus  Guard
Norton Anti-Virus          Virus  Intercept
McAfee Associates          Vshield
Vet                        Vet-Res

                         Bye for now

                            Alan ( MCC )

------------------------------

Date:    Wed, 10 Jul 91 12:23:00 +0000
From:    [e-mail]
Subject: Keypress Virus (PC)

HELLO EVERYBODY .....

I AM A NEW MEMBER IN YOUR GROUP.

        I want to discuss a new virus in my LAN ,i'm the lan adminstrator,
which is KEYPRESS. My LAN type is 10NET , the server is TANDY 4000,IBM compatib
e
   This virus symptoms is :
     1. Damaging the SCAN.EXE
     1. Damaging the SCAN.EXE & tthe CLEAN.EXE files
     2. Hanging some of the commands of LAN loading,specially those managing
        the connection with modem on an RS232 serial port.
     3. Hanging the commands of management of the Ram extensions, i use the
        386MAX commands.
     4. Finally , when scanning and cleaning from a write protect floppy
        it make horrible sounds trying to cut the protecion shields.

        Even when i succeed to remove them, they just come back again showing
     at the top right corner of the screen the word SAMSOFT.

        I have tried scan & clean with McAfee scan ver. 6.9V75.

I WOULD LIKE TO KNOW OF ANY NEW ANTI VIRUS PACKAGE AND ANY SUGGESTION FOR
PROTECTING THE LANS FROM VIRUSES.

                                                MONIRA B.W. MOHAMED
                                        PROGEMMER,SYSTEMS ENGINEER
                                        A.O.I. HEAD OFFICE

------------------------------

Date:    Wed, 10 Jul 91 15:01:00 +0300
From:    Y. Radai <[e-mail]>
Subject: Re: Problem with GUARD (PC)

  Tim Martin writes:
>   I received GUARD from Y. Radai today.  I think I found a
>significant problem with it.  On rebooting from the hard drive, after
>an infection by "stoned", Guard removes stoned from the PBR but not
>from memory.  ....  If
>instead a floppy disk is formatted, chances are it will be infected
>with the stoned virus.  ....

As is stated in the GUARD.DOC file, "GUARD ... does not prevent infec-
tion of RAM or of diskettes."  It is designed to protect only the hard
disk.  For protection of diskettes and memory you have write-protect
tabs, generic monitoring programs, known-virus scanners, etc.

  Several people seem to be under the impression that GUARD is sup-
posed to be a panacea for virus problems, and are disappointed when
they find that it is not.  GUARD is intended to block a *specific
security hole*: that which occurs because ordinary anti-viral pro-
grams, such as those mentioned above, don't get a chance to activate
when booting is performed from a diskette.  GUARD is not designed as a
*substitute* for other programs, but as a *supplement* to them.
Please judge it in that light.

>In my opinion, "Guard" doesn't give us anything that is not already in
>Padgett's DiskSecure package.

Who ever said it does?  Actually, I haven't yet had the opportunity
to try DiskSecure (though I'm willing to bet that GUARD contains quite
a few features that DiskSecure doesn't).  I guess the most authorita-
tive answer on such a comparison will come from Padgett.

>When it is infected by a stealth virus (at least by the Empire family
>of viruses) guard does not permit the computer to be rebooted from the
>hard drive, and automatically remove the virus from the hard disk.

This is a serious claim, and will have to be investigated.  (That,
after all, is what testing is for.)  Thanks, Tim.

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]
                                     [e-mail]

 P.S.  I take this opportunity to apologize to the person who received
six copies of the GUARD.UUE file.  (I sent only one, honest!)  And if
anyone who requested it has not received it within (say) 5 days of his
request, please write to me again.

------------------------------

Date:    Wed, 10 Jul 91 18:37:00 +0300
From:    Y. Radai <[e-mail]>
Subject: Re: Apology; Malicious Programs Definitions Revisited

  William Walker writes:
>                                 Finally, postings from several people
>caused me to correct my spelling of the plural of "virus."  The
>correct spelling is "viri," according to the rules of spelling in the
>Lincoln Library of Essential Information (my dictionary doesn't have a
>plural listed for "virus").

NO, NO, NO.  (That's getting to be a popular retort.  Two people used
the very same expression when correcting a statement by Mike Ramey!)
Take into account the following facts:

  1.  Webster's Third New International Dictionary gives the plural
form of the word explicitly; it's "viruses", not "viri" (and certainly
not "virii"!!).
  2.  Since our use of the word "virus" is by analogy with the micro-
biological use, try looking at a book in that area.  Again, you'll
find that the only plural used is "viruses".
  3.  As for the book you mention, take a closer look.  You might
find (as I found in another grammar book) that not all words ending
in "-us", even if they are of Latin origin, form their English plural
by replacing the "us" by "i" (as in Latin itself); many simply suffix
"es".  If you don't believe me, try using "boni", "circi", "chori",
"campi", or "cauci" in a sentence.

  Summary: "Viri" is fine if you're speaking Latin, but in English
it's "viruses".

------------------------------

Date:    Wed, 10 Jul 91 15:06:33 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Self testing; New viruses; Beta testing; Translations (PC)

Several subjects...

Self-testing:
I wrote about a self-testing program yesterday - saying it was useless against
stealth-viruses and overwriting viruses, but as others have pointed out it is
even worse than that - a routine which only checks the program in memory is of
no use whatsoever.  There exist programs for adding self-test to most
programs, but they cannot detect infection by Frodo and a few other
sophisticated stealth viruses.  It is possible for a self-test program to
detect those viruses, but I know of no such program available now - they are
all on the drawing board.

New companion virus:
Until now the only known companion viruses were AIDS II and TPWORM.  Now
the third one has been discovered, and it is by far the most sophisticated
one.  It is a 351 byte COM virus, called Twin-351.  Unlike the other two
companion viruses it stays resident in memory, intercepting the
Findfirst/FindNext calls.  As the files containing the virus are also marked
as "hidden", the virus is able to hide quite efficiently, unless a program
reads the directory directly.  Has anyone heard of this virus outside Norway ?

Mule:
One of the more interesting variants of Jerusalem is the 'Slow' virus.  It was
first reported in Australia, but sources there say it may have arrived from
Thailand.  A related variant was discovered later in California, and named
Scott's Valley, after the place of discovery.  What makes these variants
interesting is the addition of encryption - apart from it they are
more-or-less standard variants of Jerusalem.  Recently a new encrypted variant
of Jerusalem was discovered in Australia.  My personal opinion is that the
viruses have a common auther, but this new one uses a different encryption
algorithm, and is not detected by the same pattern as the other two variants.
To detect it, the following pattern can be used

Mule        2E8A 262F 0E3E 3027 43E2 FA59 585B 1FC3
(or, for users of F-FCHK)
Mule        3+5m6kpjdmgjUlsuQbMSM-gEm7ZR7Wlgs+AFojmN5jwum94OmLjLjoAt5a5aMofWgN

The virus is 4112/4117 bytes long, and contains the text "My name is Mule"

Beta-testing?
I am sending out copies of version 2.0 of my program to anyone willing to do a
bit of testing - let me know if you are interested.

Cracker Jack:
There is a crackpot in Milan, Italy who is producing an incredible number of
viruses.  Most of the viruses are variants of Murphy, or some other viruses,
which are available in source code form.

He gives them names like "Exterminator", "Demon" and so on - expecting us to
distribute the viruses in the reasearch community, and make him "famous".
One of the viruses was not named according to his wishes - he called one of
them "Patricia", but in accordance with the rule that viruses should not be
named after virus researchers, (therefore the "Solomon" virus should be
known as Jerusalem-1600/1605), it was named "Smack", because of the following
text it contains:

        Special message to Patricia Hoffman: I love you!!!!!!!! SmackSmack!!
        Can you give me your telephone number??? Ciao bellissima!

He did not like this name change, as is evident from a text message in one of
the viruses in the next batch we got from him:

    Patricia does not function correctly, because I haven't run it before send.
    Now I'm debugging it
    ehehehehehahahahahahah

    Smack Virus....what a horrible name!!!!!!!!!!!!!!!!!!!

    Compliments to the Dark Avenger for the nice viruses
    excuse me if I create some variants of your beautiful viruses
    Viruses are a nice thing!!

His viruses are available on one of the Italian virus BBSes, and probably
elsewhere as well, but they are (as far as I know) not known in the wild.
My question - he is probably going to continue creating viruses, but should
we play the game the way he wants - what I would like to propose is a name
change - just group all his viruses together and give them a name like
"Stupid Jack" or "Crackpot", followed by a number. We would then have

    Crackpot-272    (not "Demon")
    Crackpot-1951    (not "Goblin")

and so on for his 20 (or whatever) viruses.  Opinions ?


Translations:
I am having my anti-virus package translated into several different languages,
including Norwegian, Finnish, French, German, Italian and Spanish - in
addition to English and Icelandic.  Portugese and Turkish versions have
also been discussed.  If anybody is interested in the production of a version
for any other language, please contact me.

- -frisk

------------------------------

Date:    Wed, 10 Jul 91 11:18:00 -0400
From:    "Dr. Harold Joseph Highland, FICS" <[e-mail]>
Subject: re: Research

Hope this reaches you in response to your request on Virus-L.  Will
forward to Ken van Wyk as well for inclusion in Virus-L.

[1]  The mathematical in COMPUTERS & SECURITY was by Dr. Winfried Gleissner
and appeared in Vol. 8, No. 1, pp 35-41 [February 1989].

[2]  Dr. Klaus Brunnstein of U of Hamburg [Germany] presented an excellent
paper on spread of virus [counts, new ones, mutations, etc.] at Fourth
Annual Computer Virus and Security Conference in NYCity in March 1991.
You should read this.

[3]  Dr. Frederick Cohen also has some estimates of virus spread.

[4]  What school are you at?  What is your address?

[5]  If you school library does not have C&S I might be able to direct
you to one near you that has.  Too bad you're not near NY.

HJH

   -----------------------------------------------------------------------
  |                                                                      |
  |                      Dr. Harold Joseph Highland, FICS                |
  |       Managing Director, COMPULIT Microcomputer Security Laboratory  |
  |   Distinguished Professor Emeritus of State University of New York   |
  |  Chairman, IFIP/WG11.8 on Information Security Education & Training  |
  |             Editor-in-Chief Emeritus of Computers & Security         |
  |            562 Croydon Road  Elmont, New York 11003-2814  USA        |
  |                                                                      |
  |    Voice: [phone]            Telex: [phone] [MCIUW]  |
  |    Electronic mail:     [e-mail]                 |
  |    X.400: C=US/A=MCI/S=Highland/D=ID=4065012     MCI Mail: 406 5012  |
  |                                                                      |
   -----------------------------------------------------------------------

------------------------------

Date:    Wed, 10 Jul 91 17:41:00 +0300
From:    Y. Radai <[e-mail]>
Subject: Virus Bulletin Conference

  This is a forward from Edward Wilding, editor of the Virus Bulletin:

  --------------------------------------------------------------------

The Virus Bulletin Conference takes place on September 12-13th 1991 at
the Hotel de France on the Channel Island of Jersey in the UK.

Speakers include Vesselin Bontchev, Ross Greenberg, Yisrael Radai, Jim
Bates, Jan Hruska, Steve White (IBM), Fridrik Skulason, John Norstad,
Ken van Wyk, David Ferbrache and Gene Spafford, plus presentations
from Digital, New Scotland Yard's Computer Crime Unit, and corporate
computer security specialists responsible for implementing real world
anti-virus measures worldwide.

Subjects include an introduction to MS-DOS viruses, the Bulgarian
'virus-factory', anti-virus tools and techniques, integrity checking
methods, disassembly and forensics, IBM's strategy, future programming
trends, Macintosh viruses, CERT, Unix, Digital's strategy, blackmail,
extortion and espionage through logic bombs, trojans and covert
channels and corrupt working practice.

Registration information is available from Miss Petra Duffield in the
UK. Tel. [phone], Fax. [phone].

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 121]
******************************************

VIRUS-L Digest   Wednesday, 10 Jul 1991    Volume 4 : Issue 122

Today's Topics:

New reviews
Review of TBSCAN (PC)
Product Test - - ViruSafe (PC)
Product Test - - VIRx (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Wed, 10 Jul 91 15:17:15 -0400
From:    Kenneth R. van Wyk <[e-mail]>
Subject: New reviews

The following three anti-virus product reviews have been received over
the past several days.  I decided to bundle them together in one
digest as time/space permitted.  All three, and a BUNCH of previous
reviews by both Rob Slade and Chris McDonald, are available by
anonymous FTP on cert.sei.cmu.edu (NEW IP number = 192.88.209.5) in
the pub/virus-l/docs/reviews directory.

As always, a wholehearted thanks to Rob and to Chris for their
excellent contributions.

Ken

Kenneth R. van Wyk
Moderator VIRUS-L/comp.virus
Technical Coordinator, Computer Emergency Response Team
Software Engineering Institute
Carnegie Mellon University
[e-mail]  (work)
[e-mail]   (home)
[phone]  (CERT 24 hour hotline)

------------------------------

Date:    Fri, 28 Jun 91 15:26:28 -0700
From:    [e-mail] (Rob Slade)
Subject: Review of TBSCAN (PC)

                               Comparison Review

Company and product:

Frans Veldman
ESaSS B.V.
P.o. box 1380
6501 BJ  Nijmegen
The Netherlands
Tel:  31 - 80 - 787 771
Fax:  31 - 80 - 777 327
Data: 31 - 85 - 212 395
    (2:280/200 @fidonet)
c/o Jeroen W. Pluimers/Smulders
P.O. Box 266
2170 AG Sassenheim
The Netherlands
work:  [phone]   9.00-17.00 CET
home:  [phone]:00-23:00 CET
email: 2:281/521 or 2:281/515.3
email: [e-mail]
       [e-mail]
       ugw.utcs.utoronto.ca!rulgl.LeidenUniv.nl!FTHSMULD
Thunderbyte Scan promotional programs

Summary:

Resident and non-resident scanner and boot sector repair programs

Cost   free of charge

Rating (1-4, 1 = poor, 4 = very good)
      "Friendliness"
            Installation      2
            Ease of use       3
            Help systems      3
      Compatibility           2
      Company
            Stability         3
            Support           2
      Documentation           2
      Hardware required       3
      Performance             2
      Availability            2
      Local Support           1

General Description:

The programs tested are TBSCAN 2.2 dated 910314, TBRESCUE 1.2 dated
910211, and TBSCANX 2.6 dated 910419.  These are "freeware" (no charge
but copyright) programs distributed to promote the Thunderbyte
security card (product not available for testing.)  The scanners use
IBM's VIRSCAN signature file format, and are very fast, but provide no
disinfection.

                  Comparison of features and specifications


User Friendliness

Installation

Installation is a matter of copying the programs to disk and deciding
how to run them.  The documentation, while clear enough as to use,
does not supply much in the way of direction as to the invocation of,
say, the resident scanner, TBSCANX.

In another sense, the "use" of TBRESCUE is also its "installation", in
the production of a repair file, while it could be used, in its
"compare" mode, to check the system areas at boot time.

While an experienced user will be able to determine how best to use
these programs fairly easily, novice or intermediate users may not
have sufficient information to use them effectively.

Ease of use

The programs are fairly easy to use.  The command line switches should
not be strictly necessary for effective use, but can provide
significant extra information or use for the expert.

Help systems

If invoked incorrectly, the program displays a brief summary of the
command line switches.

Compatibility

During testing significant problems were encountered.  The
documentation does warn against the use of resident or pop-up
programs, and this may have contributed to the problem.  At this time,
the problems remain unresolved.

On one machine, TBSCAN would fail to check any files after a memory
checking program had been run.  No error message was displayed.

Company Stability

Unknown, but one report indicates that the company has recently made a
significant sale to Phillips.

Company Support

Contacts with the company have been sketchy so far.

Documentation

The English documentation is definitely written for the intermediate
or experienced user, and contains numerous grammatical errors.  It
does, however, provide some helpful and realistic discussion of the
limitations of these types of programs.  (This is to be expected,
since the programs are used for the promotion of the hardware card.)

Hardware Requirements

None stated.  Difficulty was encountered in running the program on an
old IBM compact/portable, but may have been related to programs run
before TBSCAN.

Performance

TBRESCUE will not work on a "floppy only" system.

TBSCAN and TBSCANX fail to identify the "Stoned" virus in memory,
although TBSCAN will identify it on disk.  TBSCANX will not alert you
to a boot sector infection when accessing (DIR or other) an infected
disk.

TBSCANX 2.2 failed to identify the Jerusalem virus in infected files,
although TBSCAN would identify them on disk.  TBSCANX 2.6 has fixed
this, but no longer permits you to run the files.  It still does not,
however, prevent Jerusalem from "going resident" and infecting other
files.  (Subsequently infected files, for some reason, will run,
although TBSCAN will terminate with no error message.  It will do this
when infected with a virus as well.)

Local Support

None provided.

Support Requirements

On a "scan only" basis, the program is simple to use.  Installation,
and disinfection will require expert assistance.

                                 General Notes

The speed of the scanner, and its ability to use IBM's VIRSCAN
signatures (and have the user extend the signature file) make this a
handy tool for "first line" defense.  It does not, in its present
state, seem advisable to depend upon this product alone.

Also note - although the documentation states that the program is free
of charge, occasionally when invoking the TBSCANX program a message
appeared urging the user to register this "evaluation copy".

copyright Robert M. Slade, 1991   PCTBSCAN.RVW   910612

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Mon, 08 Jul 91 10:46:14 -0600
From:    Chris McDonald ASQNC-TWS-R-SO <[e-mail]>
Subject: Product Test - - ViruSafe (PC)

*******************************************************************************
                                                                          PT-24
                                      July 1991
*******************************************************************************


1.  Product Description:  ViruSafe is a commercial software package to detect,
disinfect and prevent computer viruses and malicious programs for the MS-DOS
environment.

2.  Product Acquisition:  ViruSafe is available from EliaShim Microcomputers,
520 W. Highway 436, Suite 1180-30, Altamonte Springs, FL 32714.  The commercial
telephone number is Area Code 407-682-1587.  The FAX number is Area Code 407-
869-1409.  The suggested retail price for a single copy is $80.00.  Site
licenses are available.

3.  Product Testers:  Chris Mc Donald, Computer Systems Analyst, Information
Systems Command, White Sands Missile Range, NM 88002-5506, DSN:  258-4176, DDN:
[e-mail] or [e-mail].

4.  Product Test:

    a.  I obtained an evaluation copy of ViruSafe (Version 4.02) in May 1991
from Mr. Bob Greenwald, the government account specialist for EliaShim
Microcomputers.  Mr. Greenwald had obtained my name and address from other Army
representatives.  The software arrived on a 5 1/4" write-protected disk with
a 56 page User's Manual.

    b.  Product tests occurred on the following systems:  (1)  Unisys PC, Model
3137, MS-DOS 3.10, 512K; and (2)  Unisys PC, Model 3137, MS-DOS 3.30, 640K.  Th
e
minimum hardware and software configuration is as follows:  an IBM PC/XT/AT or
compatible computer using the MS/PC-DOS (Version 3.00 and up) with 512K.
Actual tests occurred from 24 May through 5 July 1991.

    c.  ViruSafe has several major components which a user can generally invoke
from a menu or from the DOS command line.  The first program, UNVIRUS.EXE,
performs detection and removal of known computer viruses and malicious
programs.  The second program, PIC.EXE, records information about files and
checks their integrity for signs of change.  This information includes the size
of the file, its contents, the date and the time.  The third program, VC.EXE,
detects and removes viruses active in memory and in the boot sector.  The
fourth program, VS.EXE, installs as a terminate-and-stay-resident (TSR) program
that detects and identifies viruses when they attempt to enter memory and
prevents infection of programs and boot sectors.  The fifth program, VSCOPY.EXE
,
performs the DOS COPY function only after it checks that what a user is
attempting to copy is not infected by a known virus.  The sixth program,
VSMENU.EXE, is the menu-driven utility through which a user may operate
ViruSafe after installation.

    d.  ViruSafe has an utility for installing and uninstalling itself.  The
User's Manual contains instructions for using the program to test one's system
before actually installing it on a hard drive.  The instructions were adequate.
One invokes the menu by the command "vsmenu" at the DOS prompt.

    e.  Version 4.02 contains viral definitions for 412 known viruses and
mutations.  ViruSafe does identify the ten viruses which John McAfee once
proposed account for 95% of all reported infections.  ViruSafe can identify 92%
(i.e., 25 out of 27) of those viruses characterized as "common" by Patricia
Hoffman in her Virus Summary List, 15 May 1991.

    f.  Although I do not have code for all the malicious programs which
ViruSafe claims to detect, it did identify those 60+ viruses in my possession.
When ViruSAfe identifies a known malicious program, it gives the user an
audible and visual alarm if one has directed the program to report such
information to the screen.  If one chooses to have the program direct all
results to a log file or to a printer, there is no audible or visual alarm.
The log file option will cause results to appear on the screen; however, the
screen clears automatically at the completion of the detection operation.

    g.  The "Check and Remove" menu has various options to check only for
virus signatures, to check and remove program viruses, to check and remove boot
sector viruses, to check and remove all file viruses, and to check only for a
virus in memory.  I tested all these options which functioned as documented.  I
did verify that all "check and remove" options were automatic.  So, for
example, if ViruSafe detects a virus in an .exe file, it will attempt to remove
the virus without any further user authorization or intervention.  The user
will have no permanent record of the detection and removal unless he or she has
asked for a printer or log file result.

    h.  The vendor representatives emphasized the disinfection capabilities of
ViruSafe in their discussions with me prior to the actual test.  I can say that
the product performed as advertised against those viruses in my possession.
One of the main menu options is a "List of Viruses Handled".  This list
identifies those viruses and malicious programs which ViruSafe can actually
remove.  I found this an extremely nice feature because I could determine in
advance, if I choose to do so, whether ViruSafe would perform disinfection.

    i.  The Program Integrity Check (PIC.EXE) option in the VSMENU offers a
user these features:

    (1)  Check Integrity of Marked Files

    (2)  Recalculate Marked Files

    (3)  Display List of Marked Files

    (4)  Mark and Save Boot Sectors

    (5)  Mark Programs

I tested all the options which performed as indicated.  I intentionally changed
the contents and size of various files.  In each case there was a notification.
I must emphasize that I made no deliberate attempt to defeat the mechanism
since that is beyond my capabilities.  The User's Manual states that Program
Integrity Check (PIC) is a "special digital signature, calculated for marked
files".  There is no other information on what exactly this calculation
entails.  I am not an expert on this subject but discussions on the Internet
and on Virus-L in particular can provide any user with additional information
in this area.

    j.  The VS.EXE TSR program performed as documented.  I successfully
caused the program to alarm under all of the stated events.  I must qualify
that malicious code in my possession is limited.  Any certification of 100%
effectiveness is beyond my capabilities.  The list of options allows one to
customize protection against "unknown" malicious programs and to closely
monitor system activity in general.  The VSMENU presents a user with these
options:

    (1)  Check Resident Programs (TSR)      [The default is OFF.]

    (2)  Check Access to Program Files      [The default is OFF.]

    (3)  Check Write to Boot Sectors        [The default is ON.]

    (4)  Check Diskettes Infection          [The default is ON.]

    (5)  Check Memory Infection             [The default is ON.]

    (6)  Write Protect Hard Disk            [The default is OFF.]

    (7)  Sound Warning Alarm                [The default is ON.]

    (8)  Check Memory Size Changes          [The default is ON.]

    (9)  Check Virus on Program Exit        [The default is OFF.]

    k.  The VSCOPY.EXE program functioned as described in the document.  I
tested with boot sector, .com and .exe viruses.

    l.  There is an Advanced Features option in the main VSMENU.  I tested
three of the selections which functioned as advertised.  I did not test the
selections to restore or to repair the master hard drive boot sector and
partition table.  The User's Manual in my opinion oversells the significance
of the features to display a boot sector and to provide a memory allocation
map.  These are not very helpful tools for viral and malicious code detection.

5.  Product Advantages:

    a.  ViruSafe provides a comprehensive approach to malicious code protection
in one program.  It offers detection, disinfection and prevention--a trend
which most commercial vendors now follow.

    b.  The product provides a good menu system to assist the novice user.

    c.  The product by version 4.0 allows a user to add new virus signatures
without a formal upgrade.  [Note:  I did not have the opportunity to test this
feature.]

    d.  EliaShim Microcomputers has established a credible reputation for
technical support of its products.  The technical representative was extremely
helpful during the evaluation period.

6.  Product Disadvantages:

    a.  The cost of the product may discourage many users who are already on
tight budgets.  Even if one pursued a site license agreement, it may be that
the risk management assessment will not support such protection for every PC
within the organization.

    b.  The User's Manual is accurate, but clearly has been overtaken by
upgrades to the product.  For example, although I received the Lan version of
the product, the manual has very little to say about network operations.  The
read.me file on the program disk contains information that at least by version
4.0 a user may add new virus signatures without a formal upgrade.  The manual
is silent on this subject.  There are other minor features which I noticed in
running the program which would be nice to document formally.

    c.  The TSR program offers a variety of protection capabilities which the
experienced MS-DOS user will appreciate.  It remains an open question as to
whether the majority of users within an organization will be able to configure
the TSR themselves, or whether they will be able to interpret and respond to
respective alarms.

7.  Comments:

    Fred Cohen's original paper on his first computer virus experiments
concluded that detection of viruses by their appearance or behavior was
"undecidable".  Yet seven years after the publication of his work, detection of
viruses by their appearance and behavior remains the most common form of viral
defense for the MS-DOS environment.

    ViruSafe provides the mechanisms to monitor attributes of change and to
recognize a virus by its appearance.  It also has an intrusion detection
capability through its TSR program.  The challenge for the user remains the
interpretation of what the TSR identifies as "suspicious" activity.  This
challenge is not unique to ViruSafe.  It does reinforce the proposition that,
if one chooses to acquire a product which integrates detection, disinfection
and prevention, one must have a strategy for supporting users in the
interpretation of alarms and probably in the actual configuration.

    The National Computer Security Association has issued a report "Virus
Scanners:  An Evaluation", dated March 4, 1991.  The report evaluates an
earlier version of ViruSafe so readers should recognize that my comments
pertain to version 4.02.  I obtained a copy of the report after the majority of
my tests were completed.  I am happy to report that it provided a quality
control measure on my own modest efforts.

FOR FURTHER REFERENCE:

PRODUCT TEST NUMBER              DATE            PRODUCT

PT-3                             November 1989   VIRUSCAN
                 (Revised February 1991)
PT-5                             December 1989   VIRUS BUSTER
PT-11                            June 1990       ANTI-VIRAL SEARCH, 2.24
                 (Revised February 1991)
PT-12                            June 1990       VIRUCIDE
                 (Revised February 1991)
PT-17                            August 1990     F-PROT
                 (Revised May 1991)
PT-23                            March 1991      VIREX-PC
                 (Revised May 1991)
PT-28                            February 1991   NORTON ANTIVIRUS
                     (Revised 12 February 1991)
PT-34                            April 1991      IBM ANTI-VIRUS
PT-36                            June 1991       CENTRAL POINT ANTI-VIRUS

                       5

------------------------------

Date:    Wed, 10 Jul 91 08:38:08 -0600
From:    Chris McDonald ASQNC-TWS-R-SO <[e-mail]>
Subject: Product Test - - VIRx (PC)

*******************************************************************************
                                                                          PT-41
                                       July 1991
*******************************************************************************


1.  Product Description:  VIRx is a copyrighted program written by Ross M.
Greenberg to detect computer viruses and malicious programs.  VIRx is the
detection portion (VPCScan) of the commercial protection program VIREX-PC
(reference PT-23, revised May 1991).

2.  Product Acquisition:  The program is free.  Mr. Greenberg has made it
available on many bulletin boards and software repositories, to include the
MS-DOS repository on simtel20 [192.88.110.20].  The current path on simtel20 is
pd1:<msdos.trojan-pro>virx16.zip.

3.  Product Tester:  Chris Mc Donald, Computer Systems Analyst, Information
Systems Command, White Sands Missile Range, NM 88002-5506, DSN:  258-4176, DDN:
[e-mail] or [e-mail].

4.  Product Test:

    a.  I acquired version 1.5 and version 1.6 of VIRx from the simtel20 MS-DOS
repository.  Mr. Greenberg provided the programs directly to our repository
manager.

    b.  Product tests occurred on the following systems:  (1)  Unisys 286 PC,
Model 3137, MS-DOS 3.10, 512K; and (2)  Unisys 386 PC, Model PW 820-F, MS-DOS
4.01, 8MB.

    c.  Version 1.6 contains viral definitions for 501 known viruses,
variations and malicious programs.  VIRx can identify 96% (i.e., 26 out of
27) of those viruses characterized as "common" by Patricia Hoffman in her
Virus Summary List, 15 May 1991.

    e.  Although I do not have code for all the malicious programs which
VIRx claims to detect, it did identify 60+ viruses and variations in my
possession.  The program did not detect a copy of the Virus-101 research virus,
although documentation in VIRx version 1.6 identifies it as detectable.  I used
both the normal and -L "long" scan options with negative results.  The Virus-
101, according to several virus catalogs and summary lists, does nothing but
replicate, and is for all practical purposes extinct in the real world.  McAfee
Associate's VIRUSCAN, Skulason's F-PROT and the Norton Anti-Virus product were
three programs which did alarm on my copy of the Virus-101.

    f.  One invokes the VIRx program by the syntax "virx [drive specification]"
or for example "virx c:\".  By default the program will only scan files with
known executable extensions, such as .com and .exe.  The more significant
options include switches to scan only a specified or a default directory; to
scan the entire contents of a file or a "long" scan; to scan all types of files
not just those with executable extensions; to record the results of a scan
operation in a log file; and to scan memory above 640K to just under 1
Megabyte.

    g.  I tested all these options which functioned as described in the
documentation file.  The only false positive or conflict which I found in
running VIRx against other detection programs was that it identified two
executable programs within the commercial program ViruSafe as infected with the
"Stoned-A (New Zealand 1)".  I did test for conflicts against Viruscan,
Avsearch, Virucide, F-PROT, Virex-PC, ViruSafe, Norton Anti-Virus, IBM
Anti-Virus Product, TbScan, and Central Point Anti-Virus.

5.  Product Advantages:

    a.  VIRx appears to provide excellent detection capabilities at no cost.

    b.  The operation of the program is simple.  VIRx is one of the fastest,
if not the fastest, detection program available at this time.

    c.  The author of the program has established a credible reputation for his
work.

6.  Product Disadvantages:

    a.  Free programs may not always be free.  Microcom has a marketing
interest in encouraging users to migrate from the free detection program to its
more comprehensive commercial program Virex-PC.  One cannot predict how long
Mr. Greenberg or the vendor will allow users the free use of one-third of its
commercial program.

    b.  VIRx is a detection program only.  Users will need some other program
for disinfection and prevention capabilities.

    c.  There is naturally no formal technical support for the product.  While
it is possible to contact Mr. Greenberg over the Internet, Microcom will only
support the "complete version of the VIREX-PC program".

7.  Comments:

    The National Computer Security Association has issued a report "Virus
Scanners:  An Evaluation", dated March 4 1991.  The report evaluates an earlier
version of the VPCScan element of VIREX-PC.  While it would be unfair to
make a direct comparison between the VPCScan evaluation and this product test
of version 1.6 of VIRx, a reader can obtain additional information and
confirmation of its detection capabilities.

    VIRx documentation for the last several versions states that the program
will warn a user when it becomes "outdated".  This is a welcome change from the
first version in which the program would cease to function on a specified
cut-off date.  The notification will alert a user to the need to obtain an
update.

    A final observation is that, while Mr. Greenberg has issued versions 1.4,
1.5, and 1.6 of VIRx, I as a registered user of VIREX-PC have yet to receive
any notification from Microcom of an actual upgrade to the commercial
product.  Registration, according to the literature, should result in automatic
notifications of all revisions when they become available.  This reinforces for
me the position that one cannot rely exclusively on a single product for viral
protection.  In this case the availability of other programs for disinfection
and prevention becomes essential until such time as the vendor revises
VIREX-PC.  It also supports Mr. Greenberg's documentation which suggests that
one use VIRx in conjunction with the current version of the commercial program.



FOR FURTHER REFERENCE:

PRODUCT TEST NUMBER              DATE            PRODUCT

PT-3                             November 1989   VIRUSCAN
                 (Revised February 1991)
PT-5                             December 1989   VIRUS BUSTER
PT-11                            June 1990       ANTI-VIRAL SEARCH, 2.23e
                 (Revised February 1991)
PT-12                            June 1990       VIRUCIDE
                 (Revised February 1991)
PT-17                            August 1990     F-PROT
                 (Revised May 1991)
PT-23                            March 1991      VIREX-PC
PT-28                            February 1991   NORTON ANTIVIRUS
                     (Revised 12 February 1991)
PT-34                            April 1991      IBM ANTI-VIRUS
PT-36                            June 1991       CENTRAL POINT ANTI-VIRUS

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 122]
******************************************

VIRUS-L Digest   Monday, 22 Jul 1991    Volume 4 : Issue 128

Today's Topics:

Re: multi-compression
re: virus for sale
SCAN Prices? (PC)
Inaccuracies in Press
Philosophy, comments & Re: long and technical (PC)
Partition Table Query (PC) (was Re: long and technical )
Help! I'm STONED (PC)
F-PROT configuration question (PC)
SECURE.COM (PC)
Norton AntiVirus question (PC)
re: multiple compressions
Questions - list of viruses, writing a scanner
DOS virus attack (PC)
The smiling face (PC)
Re: Inaccuracies in Press on Viruses

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    17 Jul 91 20:40:03 +0000
>From:    [e-mail] (Fridrik Skulason)
Subject: Re: multi-compression

[e-mail] writes:
>Let's say I have an EXE that I've run through LZEXE. PKLITE, regardless of
>version will do a test on the file to see if the file is smaller after the
>compression is added. Since the file's already compressed, PK won't make the
>file any smaller, and will crash off, and inform the user that it can't
>compress the file.... leaving the file untouched.

Ah, but what if you first use a compression program which is not as
good as LZEXE or PKLITE.  Try for example to compress a program with
EXEPACK - PKLITE is oftem able to compress them still further...

- -frisk

------------------------------

Date:    Wed, 17 Jul 91 23:50:00 +0000
>From:    William Hugh Murray <[e-mail]>
Subject: re: virus for sale

> Granted, that to me sounds like the Hi-Tech version of selling
>anthrax...  On the other hand, there are some people in the world who
>are interested in how a virus works. (Myself included.)  Yes, this is
>not such a good idea to sell a virus, but I would rather have one
>arrive in the mail when I'm waiting for it, rather than let it sneak
>up on me some night when I'm downloading...

I am a little disappointed at such a narrow and egocentric view.
The offering of the virus for sale increases, rather than decreases,
the possibility that one will "sneak up on you some night."  Getting one
in the mail when you expect it, does not reduce, but increases, the
chance that you will get one when you do not expect it.

You reason like the man who when told the chances of a two bombs on a
plane was vanishingly small, decided to always carry his own.

Seeing the content of Jerusalem-B will tell you nothing that is not
already public.  There are no clever secrets in Jerusalem-B, and nothing
that you can learn about it from having your own copy that will reduce
your vulnerability to it.  The ability to satisfy your morbid curiosity,
at the expense of giving it a boost which it does not need, seems to me
a very bad trade indeed.

Your vulnerability is related to the total number of copies in the
world; someone offering it for sale can only influence that in one
direction.  What makes you think that all of the purchasers will treat
it with the respect with which such a dangerous artifact should be
treated?

One way to view the ethics of something that you would like to do is to ask
yourself how you would be affected if everyone else did it too.

William Hugh Murray                     203-966-4769
Information System Security             203-326-1833 (CELLULAR)
Consultant to Deloitte & Touche         203-761-3088
Wilton, Connecticut                     email: [e-mail]
                                        [e-mail]
                                        MCI-Mail: 315-8580
                                        TELEX: 6503158580
                                        FAX: [phone]
                                        Compu-Serve: 75126,1722
21 Locust Avenue, Suite 2D              DASnet: [DCM1WM]WMURRAY
New Canaan, Connecticut 06840           PRODIGY: DXBM57A


------------------------------

Date:    Thu, 18 Jul 91 02:09:18 -0400
>From:    [e-mail] (Daniel J Karnes)
Subject: SCAN Prices? (PC)

>>Date:    Tue, 16 Jul 91 16:25:36 +0000
>>From:    [e-mail] (McAfee Associates)
>>
>>Pricing depends on many factors such as the type of usage, number of
>>machines, which programs, type of upgrades, and so forth.  This makes
>>it difficult to give you a simple response.

RG>Why is it so bloody hard to get a friggin' price out of you guys, eh?

RG>Do you have a price list?  If so, publish it?

Hi Ross.. Last time I looked, the prices were very clearly listed in
the .DOC files for SCAN and the other utilities... Says right there
what it costs. Also says that if you need any other information or a
quote for a site license to give 'em a call too.

I assume that your talents include being able to read.

SPEAKING of being hard to get an answer from... I tried many times
over a period of two years to get information or even an answer from
you on your bbs and also a time or two via telephone, and finally
just gave up. What gives?

- -djk

*********************************************************************
Daniel J. Karnes - An entity of one. *  Ring MY chime sometime guy!
[e-mail] / WA6NDT / POB 7007 Nashua, NH USA 03060-7007
*********************************************************************

------------------------------

Date:    Thu, 18 Jul 91 09:03:15 -0400
>From:    Helena M Vonville <[e-mail]>
Subject: Inaccuracies in Press

Robert McClennon wrote on the Washington Post article which discussed
the possibility of a virus in the telephone software.  He was
disturbed (and rightly so) that the press does not use the jargon
correctly when describing such problems.

Fortunately (or maybe not so fortunately since we are dealing with a
certain amount of potential incompetence) the problem was not virus,
trojan, or worm related.  It was just bad programming.  The story was
updated on NPR late last week, I believe.
Helena VonVille
Ohio State Universiy

------------------------------

Date:    Thu, 18 Jul 91 10:13:26 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: Philosophy, comments & Re: long and technical (PC)

    First, the number of column inches devoted to one vendor
yammering about another's failure to publish (in Virus-L !) a price
list is getting out of hand. This kind of diatribe serves no
constructive purpose in this forum.

    In the same vein, I have learned that to a journalist,
credibility is everything & once lost is very difficult to regain.
Quoting recognized experts out of context and distorting papers to fit
maligning prose is a quick way to ruin credibility so that even
valuable contributions are distrusted.

    Combining the two paragraphs above, I have decided that any
response to such merely allows opportunity for more yammering or yet
another distorted response & thus personally decline to do so. "Once
bitten" & all that.

    Back to the main subject, the responses and suggestions seen
so far to the question of authentication of a system (e.q. how do you
tell is an "extra added attraction" is present) again seems to be
missing a point settled some time ago:

    The simplest answer to the dilemma is to separate into two tasks:

1) Determine the BIOS entry points for interrupts needed to authenticate
   the system.

2) Authenticate the system.

    The easiest way to do this is to accomplish (1) during the
BIOS load before DOS (or any other O/S) has had a chance to muddy the
waters.  Since at BIOS time, a PC is a fully functioning computer, it
is posible to retrieve the pointers to essential elements (Interrupts
0-1Fh) and store these values in an accessable location, possibly
encrypted.

    Since these vectors (keyboard, local storage, monitor) are
still usable even after loading of the O/S. Programs can be run at any
time that use only these known clean accesses. Such programs can be
effective even in an infected single-tasking machine. These access
values may be stored either on-line, at the server level, or off-line
on floppy disks.

    If necessary, the entire subroutine for such access to the INs
& OUTs level could be maintained separately so that use of
potentially-corrupted interrupts would never be necessary.

    Given clean and authenticatable periperal paths, integrity
programs and scanners can be run at any later time with the ability to
bypass possibly untrustable elements thus rendering all currently
known stealth techniques useless.

    The authentication task may then be invoked at any time before
or after the loading of the O/S with expectation of valid results
being obtained.

    It is interesting to note that such a methodology would remove
the necessity for memory scans that have caused so much trouble lately
since no resident routines would be necessary for execution.


                            Padgett

"All is simple. If it looks complex, it has not been properly broken down."

------------------------------

Date:    Thu, 18 Jul 91 18:26:00 +0000
>From:    [e-mail] (Glenn Forbes Larratt)
Subject: Partition Table Query (PC) (was Re: long and technical )

[e-mail] (I) wrote:

>Every Saturday, the operations staff here take the time to boot each
>machine in the lab from a specially-prepared "wiper" diskette.  The
>diskette is programmed (via autoexec.bat and some special widgets
>written in-house) to format all logical hard disks in the machine,
>rebuild DOS, and reinstall the necessary drivers to connect to the
>network.
...
>we are currently working on one of our widgets so that it can
>automatically rebuild and overwrite the partition table for a complete
>"wipe".

In the course of putting the partition table aspect of this together,
I've come across some questions which I need to answer before I can go
further:

    1) I am implementing the partition table rebuild code as a
device driver to be launched from a cold boot from a floppy.  However,
the partition table has to have been already read for DOS to be
setting up drive letters internally (I assume, with all that implies
:-).  Is there a chance of having a partition table virus already in
memory from that process?

    2) Is it absolutely necessary to reboot to rebuild the DOS
drive designations after making changes to the partition table?

    3) If the answer to 2) is yes, I am considering ways of
preventing any unnecessary monkeying with the partition table.  Is a
byte-by-byte compare of the partition table bootstrap code with a
known good copy an effective means of doing this?

I thank you all in advance for any assistance.

- --
===/| Glenn Forbes Larratt      |    CRC OCIS     | "So, what do we need?" |/
==/| [e-mail] (Internet) | Rice University | "To get laid!"        |/=
=/| GLRATT@RICEVM2 (Bitnet)     |=================| "Can we get that     |/==
/| The Lab Ratt (not briggs :-) |  Neil  Talian?  |       at the 7-11?" |/===

------------------------------

Date:    18 Jul 91 16:23:15 +0000
>From:    [e-mail]
Subject: Help! I'm STONED (PC)

    I have run into a PC which ended up "Stoned" when booted off a
floppy, and a quick look at comp.virus seemed to indicate that this is
potentially not good!

    So, not being up to date on the PC anti-virus stuff out there, how
should I deal with this.  A few posted hinted at virX, but where do a find
it?  Or is there something better to use.

    Any help would be appreciated.  Replies can go to comp.virus
or by E-mail to "[e-mail]" (ignore the DECNET reply
address).

    Thanks in advance
                Olve Peersen

------------------------------

Date:    Thu, 18 Jul 91 14:42:08 -0500
>From:    BJ Watts <[e-mail]>
Subject: F-PROT configuration question (PC)

Hello,

   We are currently in the process of obtaining F-PROT for our 100 PCs
in the Business Computer Lab at The University of Alabama.  We are
also using the Novell 3.1 NetWare.  Our workstation's C drives are
write-protected, so our users can only infect the memory, their own
floppies, and the D drive which is used as a temporary drive.  We do
however have a couple of workstations for the uses of the consultants
in which the hard drives are not write-protected.  My question - Do we
need to use the F-DRIVER.SYS?  The only people who can infect the
network are those who have access to places on the server other than
their own personal directory.  These are only the consultants, and we
are aware about scanning anything before we download or use a floppy.
Any comments would be appreciated.


                         BJ Watts
                         [e-mail]

   ________________________________________ ____________________________
  :                                        :                            :
  :    BJ Watts                            :  Marriage is a wonderful   :
  :    BITNET:   [e-mail]      :    institution, but who    :
  :    INTERNET: [e-mail]      :      wants to live in an   :
  :    The University of Alabama           :        institution?        :
  :________________________________________:____________________________:

------------------------------

Date:    Tue, 16 Jul 91 10:11:00 +1200
>From:    PAT ROSSITER <[e-mail]>
Subject: SECURE.COM (PC)

There has been some discussion in comp.sys.novell about a new "virus"
called SECURE.COM which opens up and damages netware binderies.
No-one has seen it themselves yet, everyone has heard about it, so it
may be another "urban legend".  It is likely that if it does exist
someone in this group will have heard of it, or be CERTAIN that it
does not exist.

If you have information of SECURE.COM, please post something to
comp.sys.novell.

[Ed. Rumors of this program have been floating around for several
years; to my knowledge, the rumors have never been substantiated.
Unless someone can cite some specifics, I suggest that we treat this
as merely another unfounded rumor.]

Thanks
Pat Rossiter  [e-mail]

------------------------------

Date:    Fri, 19 Jul 91 11:20:25 -0400
>From:    [e-mail] (Larry W. Virden ext. 2487
      )
Subject: Norton AntiVirus question (PC)

I am a novice at MS-DOS environment, and have been asked to install
and evaluate the Norton AntiVirus software.  I would be interested in
finding out any tips, pointers, warnings, etc. concerning this package.
Is there a mailing list for customers, or online services thru
Compuserve, etc.?  I am looking for any and all sources of assistance
in this endeavor.

My goal is to test this software on the various types of IBM PC type
machines available in house and to evaluate the package's worthwhileness.
- --
Larry W. Virden                 UUCP: osu-cis!chemabs!lwv27
Same Mbox: BITNET: lwv27@cas    INET: [e-mail]
Personal: 674 Falls Place,   Reynoldsburg,OH 43068-1614
America Online: lvirden

------------------------------

Date:    Fri, 19 Jul 91 12:45:27 -0700
>From:    [e-mail]
Subject: re: multiple compressions

>From:    Dmitri Schoeman <[e-mail]>

I would like to say that multiple compressions are possible for
someone who desires to do so.  It took me approximatly 30 seconds to
succesfully accomplish a compression with both pklite and lzexe on a
program I had just written.  The method is a trivial method, which
involves no modification of any of the programs and, as I said can be
accomplished in less than 30 seconds.
- -=-=-=-=

It may be worthwhile to mention whgat version of each you are using, Dimitri.
It occurs to me that this wouold make a difference. Also, please indicate in
what order this was accomplished. For some reason, in the versions I was
running I was unable to do what you suggest, in any order...

------------------------------

Date:    Fri, 19 Jul 91 21:22:39 -0400
>From:    "Jack a.k.a. Wildside" <[e-mail]>
Subject: Questions - list of viruses, writing a scanner

This may seem like a totally rehashed question, but pleasse bear with
me.  I have been on this list some time now, and feel that I have
enough of a grasp of viri (virii?) to try and write my own version of
a detector/ fixer for virii.

Question 1: I know that there is a list, accessible by ftp, that
specifies a lot of the PC viruses, ways to detect them, and ways to
fix the data that has been corrupted.  Can someone please give me a
pointer to this?

Question 2: From all of the experienced writers out there, any hints
on what is the best approach to writing a scanner/detector/fixer?
There have been a lot of views expressed in this list and they vary
widely.

Any help on this would be very greatly appreciated.

A budding virus scanner writer (fingers crossed),
Jack a.k.a. Wildside

------------------------------

Date:    20 Jul 91 18:12:00 +0000
>From:    [e-mail]
Subject: DOS virus attack (PC)

Please be alerted...

A virus has appeared in Detroit for DOS.  The virus changes files to
hidden type and adds charters to file names.

The standard DOS scan program are not effective for this virus.

First infection was found on July 20, original infection occurred
within the previous 3 days.

As always

Ed Wright

------------------------------

Date:    Sat, 20 Jul 91 18:19:00 -0400
>From:    [e-mail]
Subject: The smiling face (PC)

I had a bug. The little animal locks up the keyboard and puts the
blinking smiling face character on the bottom left hand corner of the
screen.

It showed up once during a pcshell session. I had to reboot.  I have
checked the drives with vpscan V1.10 & and TnTVIRUS 6.80a nothing
doing. I guess I kill the animal before it got onto the hard drive,
but I have to go through all my disk and find the carrier. While I'm
doing that, does any know what this beast might be???

Colin St Rose
 Provcs@ccnyvme

A wise man/woman knows what he/she does not know.
Direct mail will be fine thank you.

------------------------------

Date:    Mon, 22 Jul 91 15:00:17 +0000
>From:    [e-mail] (Jan B. Andersen)
Subject: Re: Inaccuracies in Press on Viruses

[e-mail] (Robert McClenon) writes:

>[from] The Washington Post, [...]
>>Phone system experts have suggested that a virus might explain
>>why the failures have been occurring within days of each other
>>and at the same time of day.

>It was possible as of the date of this article (but unlikely) that
>the phone system failures were caused by a time bomb, but if so, it
>was planted as a Trojan

Not if we're talking of the same incident. The company that develops
the software in the swithes, has admitted the bug was introduced as
part of an upgrade. But, because it was such a minor upgrade, the
software had not been tested af rigourusly as it should have been. See
comp.risk (or was is comp.dcom.telecom) for more details.

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 128]
******************************************
VIRUS-L Digest   Wednesday, 24 Jul 1991    Volume 4 : Issue 129

Today's Topics:

HighMemory(Re:long & technical) (PC)
Re: long and technical (PC)
Re : multiple compressions with Pklite (PC)
re: Multiple compression
Conflicting comments
double compression
re: SECURE.COM (PC)
Anti-Virus software recommendation sought
Info sources for PC viruses wanted. (PC)
Fprot & DOS5.0 (PC)
How do managers protect networks?
Philosophy, comments & Re: long and technical (PC)
CARMEL TntVirus, A Trojan suspect. (PC)
New Devil's Dance?
Re: virus for sale
NSAi announces Computer Security Connection

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Mon, 22 Jul 91 13:34:12 +0300
>From:    [e-mail] (Vasili Bykov)
Subject: HighMemory(Re:long & technical) (PC)

In his article [e-mail] (Keith Rohrer) writes:

>>Scanner sets INT 01 ( single-step ) on itself and calls some function of
>>INT 13, setting TF simultaneously. A handler of interrupt 01 traces the
>>addresses through which the execution passes( until it returns to the
>>scanner ). It is sure that BIOS INT 13 handler resides somewhere between
>>segment adresses 0C000h and 0FFFFh. As soon as the execution gets into
>>this region, a scanner stores current address and later use it as an entry
>>point of INT 13 handler.
>>
>    Yeah, but what if I have an infected program (whose infection
>traps INT 13) in high memory?  On my machine, for one, I've got disk
>BIOS at CC00 and everything from D000 to EFFF is high RAM...
>    The advantage one *does* have in such a setup as originally
>mentioned is that you can
>just find the "real" BIOS INT13 handler location *once*, then remember
>it for that machine.

The article I wrote was too concise and the idea of it appeared to be
a bit ambiguous. I think I should explain in more details:

Using such a technique (tracing addresses during INT 13h execution) you
cannot guarantee that the address you find is the same as the one which
is set by BIOS during POST. If you have some card installed, its
firmware can re-install INT 13 on itself during ROM-scan. In such a
case the address you get is the entry point of this firmware's routine.

So the only thing you can guarantee is: this code is situated above
0C00h and below 0FFFFh memory segment (or some other values which you
choose). MAY THIS CODE BE A PART OF SOME VIRUS?

[]      In case of trivial PC without high memory the answer is *NO*,
        surely.  For those machines anything you have above 0A000h
        segment is either video data or some ROM routines. It is
        unlikely that you bought a card with virus and installed it
        into your PC.

[]      Well, so what if you have a high RAM ? I say, "No, in 9999
        cases of 10000 it is not a virus too." The reason is the
        principles of high memory organization.

If you have expanded memory, that is a memory above 0A000h segment, but
within 1 megabyte address space, you should follow Lotus-Intel-Microsoft
convention named EMS (Expanded Memory Specification) in order to
handle it. You must use EMS memory driver to do so. Usually this memory is
used for keeping huge amounts of data like spreadsheets. Some code may
be placed there too. But it *MUST NOT* be a code which handles
interrupts. Expanded memory is bankable, that is its total amount may
be (and usually is) greater than the address space it occupies. In such
a case only some part of this memory resides in address space. In order
to access your data you should first tell EMS driver to place them in
memory, to be sure that the data located where you think they are. So
if you set interrupt address to code located in expanded memory, a
situation when an interrupt occurs but a bank where virus resides is
switched off the memory space, will result in a system crash.  So
expanded memory is not the best place for a virus.

If you have extended memory, that is a memory above 0FFFFh segment, you
can use it only in protected mode of 80286/386/486 processor using
their segment selectors mechanism. MS DOS runs in real processor mode,
and you cannot reach code there via real mode's interrupt table.

Surely, some buffer code may be provided which resides in lower memory,
catches interrupts, switches into protected mode or tells EMS driver to
place bank with code into memory space, and gives control to virus
itself.  But if you take into account that different computers have
different high memory configuration, your virus should be extremely
intelligent in order to work properly with any of them. A virus of size
about 20 or 30 Kbytes is not the best one. It would not hide for long.

That's why I suggest that a code in high memory address space is not a
malicious one.

Vasya. :)

- --
- -|- Vasili Bykov -|- Moscow -|- [e-mail] -|-

------------------------------

Date:    Mon, 22 Jul 91 12:46:40 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: Re: long and technical (PC)

>From:    "Mark Aitchison, U of Canty; Physics" <[e-mail]>

>By the way, the original poster suggested that the original int 13
>vector should be restored, if the bootup checking program found a
>problem. It is better to rewrite the correct boot sector (using the
>known, clean, int 13 address), and then force a cold boot. There is
>toom much chance of some other interrupt (e.g. the timer) being
>intercepted, in which case the virus might be able to re-install
>itself after being "cleaned" from int 13.

While this is a good solution, once given the fact that a PC may be
infected, I would not trust anything that system does. e.g. Could you
trust the keyboard ? For this reason, DiskSecure was designed to lock
up the system with a terse warning message, forcing a cold boot from a
"recovery" floppy (nice to see that Central Point Software picked up
this technique for PCTools 7.0)

Consequently, a cold boot from a write-protected floppy should be the
first action followed by verification of the infection, analysis of
the charactoristics, and concluded with virus removal and
reverification.

                        Padgett

Note to DiskSecure users: If McAfee's VSHIELD is in use, it will
detect the odd boot sector used on the maintenance disk (used to boot
bare for cranky software and defragmenting), flag it as an "unknown
boot sector virus" and refuse to allow a warm boot.

Personally, this is the kind of "false positive" I like since DS has
many of the traits I would be suspicious of on a floppy, but if
VSHIELD is in use, a cold boot or other modification is necessary to
use the maintenance disk.

------------------------------

Date:    Mon, 22 Jul 91 14:24:25 -0400
>From:    Dmitri Schoeman <[e-mail]>
Subject: Re : multiple compressions with Pklite (PC)

Someone inquired about how to achieve multiple compressions, and since
it is such a trivial method to impliment I feel that it adds no threat
to the computer world to explain it.  Pklite and Lzexe both create
temporary files on disk with the "compressed" code.  If the
"compressed" code is larger than the original code it will erase the
temp file, and I am sure we are all aware of the non-permancy of the
erase command, so either by using one of the Norton utilities or, I
imagine DOS 5.0 the file can be unerased and renamed as an EXE file.
If one wishes to not allow PKlite to uncompress, or to compress the
file multiple times with PKlite, one can change the first occurance of
the letters PK(lite) which will prevent pklite from recgonizing the
file, but will still allow correct excution.  One thing which I was
unable to check, due to my virus free enviornment is if this method
will hide a virus.  It is a possiblity that, depending on the
compression scheme, the file would not be changed sufficiently to hide
the search strings, however if they rely on the location of the string
they might be fooled.  Can anyone verify if the code is sufficiently
changed by the above method?

- -----Dmitri Schoeman                               [e-mail]

------------------------------

Date:    Mon, 22 Jul 91 15:00:44 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: re: Multiple compression

    Since this shows no inclination to dieing out on V-L, it may
be of interest to clear the air. However, I am reluctant to post this
openly lest it give people ideas.

    Simply, it is very possible to multiply compress files. I have
started with EXEPACK, then gone to LZEXE, thence to PKLITE. Order is
unimportant however it does take some "fiddling" between stages to
ensure that each program succeeds.

    While such a process provides no gains in size (the result
often turns out larger than the original), it does give single-pass
signature scanners fits. Consequently, there is probably some slight
chance of a trojan using such a technique to transmit a virus or other
malicious software.

    The answer, of course, is for scanners to use a recursive
technique for unravelling files and it would be relatively easy to
check. Eternal Vigilance and all that.

                        Padgett

------------------------------

Date:    Mon, 22 Jul 91 15:16:40 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: Conflicting comments

    I just realized that in the last few days that I made two
seemingly conflicting comments reguarding when you can trust a PC.

    In issue 128, the statement was made that given knowlege of
the "clean" paths to the hardware, software could be written that
would allow disinfecting an infected machine "on the fly".

    Later, a response was posted to another comment that you must
boot cold from an infected floppy before trust is possible even if a
clean Int 13 (disk access) path is known.

    The two are not really in conflict since the first presupposes
a knowlege base that does not exist at the moment. Without this
knowlege base, the second comment holds true. ("In theory vs In
practise").

                        Padgett

        "What I said is not necessarily all of what I was thinking"

------------------------------

Date:    Mon, 22 Jul 91 13:15:02 -0700
>From:    [e-mail]
Subject: double compression

- -=-=-=-=
>From:    [e-mail] (Fridrik Skulason)
Subject: Re: multi-compression

[e-mail] writes:
>Let's say I have an EXE that I've run through LZEXE. PKLITE, regardless of
>version will do a test on the file to see if the file is smaller after the
>compression is added. Since the file's already compressed, PK won't make the
>file any smaller, and will crash off, and inform the user that it can't
>compress the file.... leaving the file untouched.

Ah, but what if you first use a compression program which is not as
good as LZEXE or PKLITE.  Try for example to compress a program with
EXEPACK - PKLITE is often able to compress them still further...
- -=-=-=

Your point well taken.  Without checking the doc files, I'd be at a
loss to tell you at what point the software makes the choice of not
bothering with the file.

I was of the idea that LZEXE, at least would cough any EXEPACK file
up. before even attempting to compress it. Unsure on this point, and
about PKL's ability in this area. BTW, I understand Phil has another
version of PKL out... 1.16, I think.

On MY BBS's, I've taken the stance that I will not accept, as uploads,
files that have been treated with PKLite, LZEXE, or EXEpack... for a
couple reasons:

1: Such files, once treated with PKL, LZEXE, or PACK, are never as
small as files that have been treated by an archiver alone, such as
LZH, ARJ or even PKZIP.  This reason alone would be enough, as far as
I'm concerned even as large as the systems are, disk space is at a
premium, as is user line tine.

2: I'm taking no chances of anything hiding inside such files.
Granted, I'm more or less convinced that the chances are pretty small
of something ever happning in this area....  a point which I've spoken
on here just recently.  Just call it an instinctive move. I get
worried about things I can't check on, I guess.

Understand, I like the idea of using PKL or what have you, on files
that can use it... once the file in question has been checked for
virus contaminants, (Indeed, I use myself, after checking each file)
but I've taken a stand against distributing files treated with such as
PKL.

While in theory, the genre of compression tools such as the PKL, LZEXE
and PACK are great, and could serve well, in light of virus
considerations and in light of the added phoneline time involved in
transferring files treated with LZ, etc, I can't see accepting such
files.

------------------------------

Date:    Mon, 22 Jul 91 22:14:00 +0000
>From:    William Hugh Murray <[e-mail]>
Subject: re: SECURE.COM (PC)

>There has been some discussion in comp.sys.novell about a new "virus"
>called SECURE.COM which opens up and damages netware binderies.
>No-one has seen it themselves yet, everyone has heard about it, so it
>may be another "urban legend".  It is likely that if it does exist
>someone in this group will have heard of it, or be CERTAIN that it
>does not exist.

SECURE.COM exists.  It is not a virus.  Rather, it is a password guessing
program.  It is not widespread and never will be.  Nonetheless, it is an
example of a program that exploits weak system implementations.  However,
it exploits implementation, not design, weakness.  Properly used, the
security features implemented in NetWare are more than adequate.

Be certain that minimum password length is set to at least 5 (five) and that
"intrusion detection" is set "on."  After that you can forget SECURE.COM.

Would God that there were such a simple defense for Jerusalem-B.

____________________________________________________________________
William Hugh Murray                     203-966-4769
Information System Security             203-326-1833 (CELLULAR)
Consultant to Deloitte & Touche         203-761-3088
Wilton, Connecticut                     email: [e-mail]
                                        [e-mail]
                                        MCI-Mail: 315-8580
                                        TELEX: 6503158580
                                        FAX: [phone]
                                        Compu-Serve: 75126,1722
21 Locust Avenue, Suite 2D              DASnet: [DCM1WM]WMURRAY
New Canaan, Connecticut 06840           PRODIGY: DXBM57A

------------------------------

Date:    22 Jul 91 23:19:28 +0000
>From:    [e-mail] (David Ivens)
Subject: Anti-Virus software recommendation sought

We are considering purchasing a site licence for Virus Buster from
Leprechaun Software.

It looks a very good package.

Any advice?

------------------------------

Date:    23 Jul 91 00:23:37 +0000
>From:    [e-mail] (Rajan Ramaswamy)
Subject: Info sources for PC viruses wanted. (PC)

greetings fellow hackers,

i would like to get some information about viruses for the
ibm-pc being the unix/c type myself, i don't know where to
start. ideally i would like the following information,
- -- a document describing principles used by known pc viruses
- -- source code to some viruses/worms, if available
- -- source code or description for writing a virus scanner
   any language is probably ok.

thanks in advance,

rajan ramaswamy

------------------------------

Date:    Mon, 22 Jul 91 19:31:36 -0700
>From:    Steve Clancy <[e-mail]>
Subject: Fprot & DOS5.0 (PC)

I recently received a reply from the user on our BBS who had the
original problem with FPROT and DOS5.0  Here it is.

Msg #: *3521  Security: 0         MAIN
 From:  ARTHUR MCCREARY           Sent: 07-20-91 18:54
   To:  SYSOP                     Rcvd: 07-22-91 16:43
   Re:  COMMENT

Steve,  I tried all the suggestions and the one that works is placing
the device driver f-driver.sys as the last entry in my config.sys.
Thanks to you and every one for their help. Arthur

- ---------------------------------------------------------------------

My thanks as well.

- -- Steve Clancy

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
%   Steve Clancy, Biomedical Library  %  WELLSPRING RBBS              %
%   University of California, Irvine  %  714-856-7996 300-2400 24hrs  %
%   P.O. Box 19556                    %  714-856-5087 300-9600 24hrs  %
%   Irvine, CA  92713   U.S.A.        %  [e-mail]          %
%                                     %  [e-mail]             %
%.....................................................................%
%       "As long as I'm alive, I figure I'm making a profit."         %
%                                           -- John Leas, 1973        %
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

------------------------------

Date:    Mon, 22 Jul 91 21:02:00 -0600
>From:    Peter Lenhart <[e-mail]>
Subject: How do managers protect networks?

Hi,

I am writing a research paper on how to protect networks against virus
infection.  I have some real good information already, but I would be
indebted to anyone who feels like they might offers some more ideas.
I would like to thank anyone in advance who might send me suggestions.
Feel free to post or to e-mail them to me.  Thanks.

Peter

=============================================================================
Internet: [e-mail]
=============================================================================

------------------------------

Date:    Mon, 22 Jul 91 21:16:06 -0700
>From:    [e-mail]
Subject: Philosophy, comments & Re: long and technical (PC)

In a recent VIRUS-L posting, A. Padgett Peterson wrote:

>         The simplest answer to the dilemma is to separate
> into two tasks:
>
> 1) Determine the BIOS entry points for interrupts needed to
> authenticate the system.
>
> 2) Authenticate the system.
>         The easiest way to do this is to accomplish (1) during
> the BIOS load before DOS (or any other O/S) has had a chance
> to muddy the  waters.  Since at BIOS time, a PC is a fully
> functioning computer, it  is posible to retrieve the pointers
> to essential elements (Interrupts 0-1Fh) and store these values
> in an accessable location, possibly encrypted.

One problem that may occur is that of BIOS-shadowing. We can no longer
assume that the BIOS is in ROM at the time that it is executed. Many
machines now copy it to faster RAM. It is possible that a virus might
intercept the BIOS call inside the BIOS itself rather than in the
interrupt table.

Relying on such an infection mechanism would limit the viability of
the virus in today's world, but as the 1M chip becomes more and more
standard, the percentage of machines that have BIOS modifiable during
execution will go up.

Fritz Schneider ([e-mail])

------------------------------

Date:    23 Jul 91 08:33:12 +0000
>From:    [e-mail] ( Mr S. Rahim )
Subject: CARMEL TntVirus, A Trojan suspect. (PC)

I got hold of Carmel Antivirus package through a bulletin board. After
having installed it on the harddisk two weeks ago, I began to have
problems. This included EXE and COM files which were working before
Carmel came on the PC.  Some files hang up while others refuse to run.

When TntVirus is activated, I performed a scan of the memory with
McAffee Scan V80, and it reported that P1 Related virus was active in
memory. Another file relating to the package when run, SCAN revealed
that Brain was active in memory.

The possibilities which arose with the indetification by Scan were
that either Carmel software was using signatures to be resident in
memory which were the same as those viruses. I tried to infect a COM
and EXE file but there was no increase in file size not the date of
modification. However during this process a directorying of the root
directory revealed that an AUTOEXEC.$$$ file had been created in the
past few minutes. I deleted that file but it appeared back again.

I am leaving this question open for discussion. Is this a work of a
trojan?

Sajid Rahim

- --
============================================================================
Internet: [e-mail]
- ----------------------------------------------------------------------------

------------------------------

Date:    Tue, 23 Jul 91 07:01:57 -0400
>From:    [e-mail]
Subject: New Devil's Dance?

Does anyone have any hard evidence about the message displayed upon an
attempted soft reboot when devil's dance is resident?  I've been
experimenting here with a version that has a different message (and
seemingly different actions) than those I've read about elsewhere.
Most of the popular scanners seem to recognize it as Devil's Dance.
Thanks for any info you can provide...

                                       Charles

------------------------------

Date:    Tue, 23 Jul 91 13:07:00 +0000
>From:    Sanford Sherizen <[e-mail]>
Subject: Re: virus for sale

Thanks to Bill Murray for raising the issue of a virus for sale.  This
is not a new situation.  About two years ago, I found out that someone
was selling copies of the Pakistani Brain virus.  I called him and
asked how I could get a copy.  He said that it was only available to
sys ops and computer security people.  He asked whether I was one or
the other and I told him that I was.  After that vigorous
authentication check, I was told to send a certified check (no
personal checks allowed) for $50 and I would get "the virus, source
code, and antidote on a disk (NOT infected)".  I decided to forgo the
opportunity.

I have been told that under U.S. law, sale of this and other viruses
appears to be legal.  However, if the seller claims it is a virus and
it is only a harmless substitute, it can be considered as mail or wire
fraud and therefore a federal violation.

Next?  "Shoppers, in aisle 3, there is a special on our generic virus."

Sandy

------------------------------

Date:    Mon, 22 Jul 91 12:12:36 -0400
>From:    [e-mail] (Kyle Myers)
Subject: NSAi announces Computer Security Connection

     National Security Associates, Inc. (NSAi) has brought the
Computer Security industry a long awaited tool " a worldwide network
with the world's largest and most current compilation of Computer
Security information.  It is a powerful tool because it is current, it
spans all platforms and Security disciplines and it has a growing
wealth of information " all accessible with a local phone call and a
Keyword search!
     The system, called the Computer Security Connection (CSC)), gives
access to: 20-25 news articles per week entered from 190+
publications; Law and computer crime; Virus information databases;
shareware; personalities and experts conducting Forums; a restricted
database of Hacker activities and "products"; Vendors of products and
services with E-mail connection; Incident reports; the "Rainbow
Series"; Back issues of ISPNews, Contingency Journal (more to come);
Events Calendar; Bibliography; Planning help for new configurations;
and more, all ReSearchable by Keyword queries!
     Current and back issues of texts such as VIRUS-L (of course!),
Computer Underground Digest and CERT Alerts available on the Internet
are now included in CSC) " and on CSC) they are ReSearchable by
Keyword queries!
     NSAi is a private company whose charter is to collect and
disseminate only Computer Security information " objectively " without
political ties, vendor pressure or bureaucracy.  Its Board of Advisors
plays an active role in providing policy input and is made up of
representatives from: Johnson & Johnson, SRI International, ISSA, I-4,
Eastman Kodak, Boeing, Mellon Bank, MIS Training Institute, Bank of
America, as well as experts in Viruses, Cryptography and Privacy "
many of whom will conduct Forums on their respective expertise.
Special interest groups and organizations now have a medium to hold
conferences and meetings in their own "Conference Rooms" and have all
their input categorized and ReSearchable.
     CSC) will invoice you for the $30.00 registration fee and
$12.50 per hour of access time.
     To gain access to CSC send your name, title, organization,
address and phone number to mbrsvcs @ incomsec.org OR FAX this
contact information to 703-758-8338.

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 129]
******************************************
VIRUS-L Digest   Thursday, 25 Jul 1991    Volume 4 : Issue 130

Today's Topics:

Re: Inaccuracies in Press on Viruses
Re: DOS virus attack (PC)
Ralf Burger (again)
re: virus for sale
F-PROT & DOS 5.0 (PC)
Re: F-PROT configuration question (PC)
Re: Anti-Virus software recommendation sought
Re: CARMEL TntVirus, A Trojan suspect. (PC)
Need prg to write-prot HD partition. (PC)
Re: New Devil's Dance? (PC)
Index of Known Malware: 998 viruses/trojans
Revised Product Test- - Virex (Mac)
Revision to the Revised Product Test on SAM (Mac)
Revision to PT-9, Disinfectant 2.5.1 (Mac)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    23 Jul 91 22:49:04 -0400
>From:    "Robert McClenon" <[e-mail]>
Subject: Re: Inaccuracies in Press on Viruses

>From:    Helena M Vonville <[e-mail]>
>
>Robert McClennon wrote on the Washington Post article which discussed
>the possibility of a virus in the telephone software.  He was
>disturbed (and rightly so) that the press does not use the jargon
>correctly when describing such problems.
[The correct spelling is either McClenon in the last four generations
or MacLennan.  -- R. McC.]
>
>Fortunately (or maybe not so fortunately since we are dealing with a
>certain amount of potential incompetence) the problem was not virus,
>trojan, or worm related.  It was just bad programming.  The story was
>updated on NPR late last week, I believe.
>Helena VonVille
>Ohio State Universiy
>------------------------------
>
>Date:    Mon, 22 Jul 91 15:00:17 +0000
>From:    [e-mail] (Jan B. Andersen)
>Subject: Re: Inaccuracies in Press on Viruses
>
>[e-mail] (Robert McClenon) writes:
[Thank you.  That spelling is correct.  -- R. Mc.C]
>
>>[from] The Washington Post, [...]
>>>Phone system experts have suggested that a virus might explain
>>>why the failures have been occurring within days of each other
>>>and at the same time of day.
>
>>It was possible as of the date of this article (but unlikely) that
>>the phone system failures were caused by a time bomb, but if so, it
>>was planted as a Trojan
>
>Not if we're talking of the same incident. The company that develops
>the software in the swithes, has admitted the bug was introduced as
>part of an upgrade. But, because it was such a minor upgrade, the
>software had not been tested af rigourusly as it should have been. See
>comp.risk (or was is comp.dcom.telecom) for more details.
>
>------------------------------

1.  My real concern was not incorrect use of "jargon" terminology so
much as incorrect characterization of the degree of public threat.
Viruses and worms, which do spread, do not spread to isolated systems
like telephone switches.  To suggest that they do is a disservice to
the public, who are likely to panic unnecessarily.

2.  We know now that the problem was not a time bomb.  I suggested
that I did not think that the problem was a time bomb.  The conclusion
that the problem was a simple bug (which I had always suspected and
had indeed posted to comp.risk) was published later than the date of
my quoted note.

3.  I was admonished off-line by a journalism student for making
unreasonable demands of journalists with a minimal number of
column-inches.  I do not demand that journalists define precise
technical terminology unless it is essential to technical
understanding.  The distinction between viruses and worms is not as
important in this context as the distinction between replicators and
non-replicators.  Bell Atlantic may have been vulnerable to Trojan
horses, time bombs, or logic bombs.  Bugs got them.  The press
suggested that there was a real risk from viruses, commonly understood
to mean replicators including viruses and worms.  I don't ask full
explanations from the press.  I do ask the absence of harmful error.
The _Washington_Post_ article contained harmful error.

------------------------------

Date:    Wed, 24 Jul 91 15:20:00 +1200
>From:    "Nick FitzGerald" <[e-mail]>
Subject: Re: DOS virus attack (PC)

Ed Wright wrote:

>A virus has appeared in Detroit for DOS.  The virus changes files to
>hidden type and adds charters to file names.
>
>The standard DOS scan program are not effective for this virus.
>
>First infection was found on July 20, original infection occurred
>within the previous 3 days.

Thanks - what great information!  I feel a lot better knowing this.  8-)

Is this _all_ that is known?  Why are you so sure it's a "virus"?  Are
you sure that you're not seeing the "aftermath" of someone having run
Norton Anti-virus on your machine?

Sorry - but with the "wealth of detail" you supplied, skeptics are
likely to wonder such things.

- ---------------------------------------------------------------------------
 Nick FitzGerald, PC Applications Consultant, CSC, Uni of Canterbury, N.Z.
 Internet: [e-mail]        Phone: [phone]

------------------------------

Date:    Wed, 24 Jul 91 07:50:19 +0000
>From:    [e-mail] (Fridrik Skulason)
Subject: Ralf Burger (again)

The new and updated How-to-write-a-virus book by Ralf Burger has just
been published - called "Computer Viruses and Data Security".

According to the publishers, the book contains the source code to
several viruses, so we can probably expect a new flood of variants
based on the published examples.

I'm not sure what the best response would be - a call for a boycott of
all books by Abacus might be a bit too drastic...but I sure don't
approve of their actions...

- -frisk

------------------------------

Date:    Tue, 23 Jul 91 22:24:49 -0700
>From:    [e-mail] (Rob Slade)
Subject: re: virus for sale

On a related note, by coincidence I happened to receive this message
tonight:

== E-Mail > Fetch > Echlin, Robert =======================================

  Subject: virus files

  Hi,

  I am a consultant.  I intend to provide training and installation
  of Central Point Anti-Virus.

  I would like to demonstrate detection and cleaning of a virus.
  Could you send me a file with a virus in it that I could copy and
  use in such a demonstration?

  If the first couple of bytes of the file are changed to zeroes,
  it could not be run and the virus could not be "transmitted".

  Yours sincerely,

  Robert Echlin



== E-Mail > Out-Box > Echlin, Robert =====================================

  Subject: virus files

  1)  Why do you intedn to specialize in CPAV?

  2)  I do exchange viral code with other researchers, but I need
  some more background on who you are.  Most of those I exchange
  with are people whose work and writings I know, and whom I have
  corresponded with for at least six months.

  3)  Your request does not indicate a sophisticated knowledge of
  the field.  If this is incorrect, please feel free to expand upon
  it, but you must realize that I receive a number of requests of
  this nature from those to whom I should *not* send such files.

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Wed, 24 Jul 91 08:27:48 -0400
>From:    Lou Anschuetz <[e-mail]>
Subject: F-PROT & DOS 5.0 (PC)

Installed DOS5.0 on my machine last night (which works well imho),
but ran into a problem with F-PROT.  If I attempted to leave the
F-PROT driver.sys in my config.sys file the machine would freeze
and complain that INT13 was modified (undoubtedly true).  Has
anyone found a work-around for this?

Thanks in advance!

Lou Anschuetz
[e-mail]

------------------------------

Date:    Wed, 24 Jul 91 22:11:02 +0000
>From:    [e-mail] (Eric N. Lipscomb)
Subject: Re: F-PROT configuration question (PC)

>   We are currently in the process of obtaining F-PROT for our 100 PCs
>in the Business Computer Lab at The University of Alabama.  We are
>also using the Novell 3.1 NetWare.  Our workstation's C drives are
>write-protected, so our users can only infect the memory, their own
>floppies, and the D drive which is used as a temporary drive.  We do
>however have a couple of workstations for the uses of the consultants
>in which the hard drives are not write-protected.  My question - Do we
>need to use the F-DRIVER.SYS?  The only people who can infect the
>network are those who have access to places on the server other than
>their own personal directory.  These are only the consultants, and we
>are aware about scanning anything before we download or use a floppy.
>Any comments would be appreciated.

We have a similar situation here at UNT.  In my main lab, I have 15
PCs that are networked, but only have 2 floppies.  It is true that my
users can "only infect the memory" on these stations, but I *still*
don't want even that to happen.  So, we've installed F-DRIVER.SYS and
F-NET to prevent the users from running any program that might be
infected.  This is also a good way for me to keep tabs on the software
on the network.  If a student is suddently unable to run a program
from the network because F-DRIVER has prevented it, I need to take a
more careful look into the rights setup on my network to see who
infected the programs and how.

Protection is not a bad thing.  Using F-DRIVER is so simple and
painless, it makes almost no sense *not* to use it.  If nothing else,
it can act as a good advanced warning system for your network.

}lips

Eric N. Lipscomb, Lab/Network Manager Academic Computing Services
Email:  [e-mail]        "Golf is something you do to make
        [e-mail]         the rest of your life look good."

------------------------------

Date:    Wed, 24 Jul 91 22:17:05 +0000
>From:    [e-mail] (Andrew Turner)
Subject: Re: Anti-Virus software recommendation sought

[e-mail] (David Ivens) writes:
>We are considering purchasing a site licence for Virus Buster from
>Leprechaun Software.
>It looks a very good package.

As with all the Anti-viral pacakages it has its pros and cons - while
not wishing to say it's any better or worse than others(It pays to sit
on the fence) I have found it a very good product. We use it widely
across campus in for staff and in student laboratories.  Additionally
the Leprechaun folks are very responsive to user input and a number of
Buster's features have come from user requests. Buy a copy and give it
a whirl.

- --
 Andrew Turner  [e-mail]
    Die, v:    To stop sinning suddenly.
            -- Elbert Hubbard

------------------------------

Date:    25 Jul 91 07:30:00 +0200
>From:    [e-mail]
Subject: Re: CARMEL TntVirus, A Trojan suspect. (PC)

[e-mail] ( Mr S. Rahim ) writes:
> I got hold of Carmel Antivirus package through a bulletin board. After
> having installed it on the harddisk two weeks ago, I began to have
> problems. This included EXE and COM files which were working before
> Carmel came on the PC.  Some files hang up while others refuse to run.
>
> When TntVirus is activated, I performed a scan of the memory with
> McAffee Scan V80, and it reported that P1 Related virus was active in
> memory. Another file relating to the package when run, SCAN revealed
> that Brain was active in memory.
>
> The possibilities which arose with the indetification by Scan were
> that either Carmel software was using signatures to be resident in
> memory which were the same as those viruses. I tried to infect a COM
> and EXE file but there was no increase in file size not the date of
> modification. However during this process a directorying of the root
> directory revealed that an AUTOEXEC.$$$ file had been created in the
> past few minutes. I deleted that file but it appeared back again.
>
> I am leaving this question open for discussion. Is this a work of a
> trojan?

I know a lot of people using TNT AntiVirus (me included) since about
half a year and there was so far no sign for such a Trojan.

Two questions raise from your problem:

1. What version do you use? The current is I think about 7.1.

2. Are you sure you got a clean copy? TNT AV is a commercial product, where
   you have to pay for normally. How reliable is your bulletin board you got
   it, when it "distributes" commercial software ??????????

bye ....................................................................  Didi

******************************************************************************
*  Universitas Basiliensis                                       InfoCenter  *
******************************************************************************

------------------------------

Date:    25 Jul 91 06:23:57 +0000
>From:    [e-mail] (Mark Medici)
Subject: Need prg to write-prot HD partition. (PC)

Pardon the wide distribution, but I am in sort of a bad situation, and
need a specific piece of software to help me out.

I am in desperate need of a reasonably priced utility that can
completely and securely write protect a directory branch or logical
partition on a PC hard disk while allowing unimpeded read access to
the protected branch/partition AND full read/write access to the
remaining branch(es) or partition(s).

The problem is simple: I've got 22 computers to put in four public
student computer sites.  These computers will not have reliable access
to a file server, so software will have to be loaded on the local
fixed disk of each system.  I can't afford the staff or my own time to
constantly clean viruses, reload software, and reconfigure
applications on these computers.  So I'd like to set up part of each
computer's 40MB disk as a write protected partition.

The ideal utility would:

  1.  Allow full read/write access to the 10MB boot C: partition of
      a 40MB fixed drive for swap space and temporary user storage.
  2.  Permit read-only access to the 30MB D: partition of the 40MB
      fixed drive for protected storage of supported programs.
  3.  Not be defeated by a user booting from his/her own diskette
      (D: would either still be read-only or be inaccessible.)
  4.  Be completely transparent to the user (no extra prompts or
      pauses during system start-up or reboot).
  5.  Be compatible with MS-DOS 5.0, MS-Windows 3.0, and applica-
      tions designed for a MS-DOS/Windows environment.
  6.  Provide a separate utility that, when used with a valid pass-
      word, provides write access to the normally protected D:
      partition.
  7.  Utility in #6 should allow the definition of more than one
      password and should keep a log of accesses for each system,
      so that different levels of maintenance staff could have
      access.
  8.  Be reasonably priced.  I have a limited budget, and can't
      afford to pay $200 per machine for this.

Of course I need to get the program, if its available, as soon as
possible so I can learn it, install it on the 22 machines, and get the
machines put out at the sites by Sept 1st.

If you know of any utility, be it public domain, shareware or standard
commercial, that might fill many of these needs, please let me know.
If you have written similar software and feel you could quickly and
successfully write a program to accomplish the above, I would be happy
to talk to you.

Please E-Mail your replies to me at [e-mail], or
call me at 908-932-2412.  I will summarize here if there is sufficient
interest.
___________________________________________________________________________
                     Mark A. Medici, Systems Programmer III
                     Rutgers Univ. Computing Services, USD
                     <[e-mail]>

------------------------------

Date:    Thu, 25 Jul 91 00:26:36 +0300
>From:    Tapio Keih{nen <[e-mail]>
Subject: Re: New Devil's Dance? (PC)

>Does anyone have any hard evidence about the message displayed upon an
>attempted soft reboot when devil's dance is resident?  I've been
>experimenting here with a version that has a different message (and
>seemingly different actions) than those I've read about elsewhere.

At least the variant of Devil's Dance I have displays this message:

"Have you ever danced with the devil under the weak light of the moon?"

                                         "Pray for your disk!"

                                     "The_Joker..."

"ha ha ha ha ha ha ha"

(maybe some more / less 'ha's - I'm not 100% sure)

All this is on grey background made of those ascii graphic characters
(ascii code 178).

Tapio Keih{nen  |  [e-mail]  |  DIO COMES - ARE YOU READY TO ROCK?
Disclaimer: This posting has nothing to do with nic.funet.fi archive server.

------------------------------

Date:    24 Jul 91 12:39:00 +0100
>From:    Klaus Brunnstein <[e-mail]>
Subject: Index of Known Malware: 998 viruses/trojans

After weeks of work and excellent assistance of David Chess, Yisrael Radai,
Alan Solomon, Padgett Peterson and some others, I just published the "Index
of Known Malicious Software: MsDos systems". It covers most of the viruses
and trojans reported in this arena (similar indices for Amiga and Macintosh
to follow later this year). When summing up, I was deeply depressed: the
index counts:
                120 virus families ("strains)") with 59 more sub-families
                    with 744 viruses, variants and clones
                    plus   7 trojans,
                and      228 single (non-strain) viruses
                plus      19 trojans
                *** totalling 998 pieces of malware ***

Though some people (including Alan Solomon) foresaw 1,000 viruses later this
year, the rise in figures has been underestimated. As this development is
likely to continue, antivirus experts should cooperate even more strongly than
contemporarily discussed.

At the same time, the July edition of VTCs Computer Virus Catalog describes
                + 8 AMIGA viruses totalling 54 viruses
                +10 Macintosh viruses totalling 20 (out of 28 existing)
                +14 PC viruses/trojans totalling 84
The disparity between "virus known" and "viruses classified" (with the aim to
maintain a good quality over quantity of classification) demands other tools
and methods for analysis, classification and production of countermeasures. We
are working harder to a more actual version of Virus Catalog; I am glad that
Mr.Jahn joined VTC (for a doctor workm on secure databanks), and that Vesselin
Bonchev will join us next week for a (not yet specified) dissertation. On the
Moreover, I appreciate any cooperation with serious antivirus experts.

VTC documents (Index of Known Malicious Software: IMSDOS.791; Index of Virus
Catalog: Index.791; all entries classified up to now) are now available from
FTP:
         Our FTP server:  ftp.rz.informatik.uni-hamburg.de
         Login anonymous
         ID as you wish (preferably your name)
         dir: directory of available information
         cd pub/virus: VTCs documents

Hoping that this works, I will be absent (with Auto-Reply on) on a sailing trip
(with my schooner "Arethusa" which is a small replica of BLUENOSE but with
staysails) until August 18. 1991.        Klaus Brunnstein, Hamburg

------------------------------

Date:    Thu, 18 Jul 91 15:06:43 -0600
>From:    Chris McDonald ASQNC-TWS-R-SO <[e-mail]>
Subject: Revised Product Test- - Virex (Mac)

******************************************************************************
                                                                          PT-10
                                           March 1990
                                       Revised July 1991
******************************************************************************


1.   Product  Description:  VIREX  is a commercial program which includes virus
detection, virus treatment, and virus prevention.  The program also  identifies
"major" Macintosh trojan horses.  The current version is 3.5 as of July 1991.

2.   Product  Acquisition:  The  product  is available from Microcom, P.O.  Box
51489, Durham, NC 27717.  There are also  several  mail  order  software  firms
which  market  VIREX, generally at substantial savings for a single copy.  Site
licensing arrangements are available from the vendor.

3.   Product  Tester: Chris Mc Donald, Computer Systems Analyst, Information
Systems Command, White Sands Missile Range, NM 88002-5506, DSN  258-4176,  DDN:
[e-mail] or [e-mail].

4.  Product Test:

    a.   I  obtained  a  copy  of  VIREX  from  MacWarehouse in July 1989.  The
purchase price at that time was about 30% below  the  manufacturer's  suggested
retail  quote.   The  registration form received with the software gave one two
options to obtain any future upgrades to the product.  The first option  was  a
$75.00  Annual  Update  Service.   For  this  fee  Microcom  (then known as HJC
Software) would provide automatic updates for a year.  The second option was to
purchase  single updates for $15.00 upon notification of any VIREX new release.
I chose the second option given  that  VIREX  at  version  2.0  identified  and
repaired  all  known Macintosh viruses as of that time.  I wanted to build some
historical knowledge as to the frequency with which updates might occur  before
committing  myself  to the automatic annual fee.  I have subsequently purchased
upgrades at the 2.1, 2.5, 3.0, 3.2 and now 3.5 version.

[Ed. The remainder of this review, and numerous other anti-virus
product reviews, is available by anonymous FTP on cert.sei.cmu.edu (IP
number= 192.88.209.5) in the pub/virus-l/docs/reviews directory.]

------------------------------

Date:    Fri, 19 Jul 91 15:50:34 -0600
>From:    Chris McDonald ASQNC-TWS-R-SO <[e-mail]>
Subject: Revision to the Revised Product Test on SAM (Mac)

******************************************************************************
                                     PT-20
                                      November 1990
                                  Revised July 1991
******************************************************************************


1.  Product Description: Symantec AntiVirus for Macintosh (MAC) is a commercial
software program for the prevention, detection, and elimination of viruses  for
the Macintosh.

2.   Product  Acquisition:  SAM  is  available from Symantec Corporation, 10201
Torre Avenue, Cupertino, CA 95014-2132 for $99.95.  However, there are  several
mail order services which offer a single copy of the product at a reduced cost.
Symantec's telephone number is 408-253-9600.

3.  Product Tester: Chris Mc  Donald,  Computer  Systems  Analyst,  Information
Systems  Command, White Sands Missile Range, NM 88002-5506, DSN: 258-4176, DDN:
[e-mail] or  [e-mail];  and  Robert
Thum,  Systems  Administrator, Information Systems Command, White Sands Missile
Range, NM 88002-5506, DSN: 258-7739, DDN: [e-mail].

4.  Product Test:

    a.   I  obtained  a  copy  of  SAM,  Version  2.0,  in  October  1990  from
MacWarehouse  in  Lakewood, NJ for $67.00 dollars.  I have previously purchased
software from this source with satisfactory results.  I upgraded to version 3.0
for $25.00 in March 1991 directly from Symantec.

[Ed. Again, the remainder of this review can be downloaded by
anonymous FTP from cert.sei.cmu.edu]

------------------------------

Date:    Tue, 16 Jul 91 11:58:05 -0600
>From:    Chris McDonald ASQNC-TWS-R-SO <[e-mail]>
Subject: Revision to PT-9, Disinfectant 2.5.1 (Mac)

******************************************************************************
                                                                          PT-9
                                       January 1990
                                     Revised July 1991
******************************************************************************

1.   Product Description: DISINFECTANT is a public domain program to detect and
to repair virus activity  for  Macintosh  systems.   The  author  is  Dr.  John
Norstad, Academic Computing and Network Services, Northwestern University, 2129
Sheridan Road, Evanston, IL 60208.  Dr. Norstad's BITNET address is  jln@nuacc;
the INTERNET address is [e-mail].

2.   Product  Acquisition:  DISINFECTANT is available on several university and
public bulletin boards.  It resides in the MS-DOS repository on the Information
Systems  Command  host  simtel20  [192.88.110.20] at White Sands Missile Range:
pd3:<macintosh.  virus>.

3.  Product Tester: Chris Mc  Donald,  Computer  Systems  Analyst,  Information
Systems  Command,  White Sands Missile Range, NM 88002-5506, DSN 258-4176, DDN:
[e-mail] or [e-mail].

4.  Product Test:

    a.  I obtained a copy of DISINFECTANT, Version 1.5, in  January  1990  from
the  Macintosh  repository  on  the  the USAISC-White Sands host simtel20.  The
repository has been registered with HQ ISC, and has been approved for operation
by  the  Commander,  USAISC-White Sands, under the policy of AR 380-19.  I have
continued to receive updates with the most recent version 2.5.1, 7 July 1991.

[Ed. Again, the remainder of this review can be downloaded by
anonymous FTP from cert.sei.cmu.edu]

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 130]
******************************************
VIRUS-L Digest   Friday, 26 Jul 1991    Volume 4 : Issue 131

Today's Topics:

Re: HighMemory(even longer & more technical) (PC)
Viral Use of Memory Over 640K; Trust (PC)
Re: CARMEL TntVirus, A Trojan suspect. (PC)
Re: Philosophy, comments & Re: long and technical (PC)
Printer paranoia
Virus Scan V57 and V77. (PC)
Re: F-PROT & DOS 5.0 (PC)
New Jerusalem - Help! (PC)
Re: Anti-Virus software recommendation sought
Terminology and Taxonomy
Re: Revised Product Test- - Virex (Mac)
Toward a Taxonomy of Malicious Programs
Re: Self-scanning executables (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    25 Jul 91 15:11:23 +0000
>From:    [e-mail] (Keith Rohrer)
Subject: Re: HighMemory(even longer & more technical) (PC)

[e-mail] (Vasili Bykov) writes:
>In his article [e-mail] (Keith Rohrer) writes:
>>>scanner ). It is sure that BIOS INT 13 handler resides somewhere between
>>>segment adresses 0C000h and 0FFFFh. As soon as the execution gets into
>>    Yeah, but what if I have an infected program (whose infection
>>traps INT 13) in high memory?  On my machine, for one, I've got disk
>>BIOS at CC00 and everything from D000 to EFFF is high RAM...
>
>Using such a technique (tracing addresses during INT 13h execution) you
>cannot guarantee that the address you find is the same as the one which
>is set by BIOS during POST. If you have some card installed, its
>firmware can re-install INT 13 on itself during ROM-scan. In such a
>case the address you get is the entry point of this firmware's routine.
>
>So the only thing you can guarantee is: this code is situated above
>0C00h and below 0FFFFh memory segment (or some other values which you
>choose). MAY THIS CODE BE A PART OF SOME VIRUS?
>
>[]      Well, so what if you have a high RAM ? I say, "No, in 9999
>        cases of 10000 it is not a virus too." The reason is the
>        principles of high memory organization.
>
>If you have expanded memory, that is a memory above 0A000h segment, but
>within 1 megabyte address space, you should follow Lotus-Intel-Microsoft
>convention named EMS (Expanded Memory Specification) in order to
                  ^^^
But my machine has no EMS; I have 1 Meg of memory on the motherboard,
and the NEAT chipset allows one's 286 machine to map high memory.
Also, on 386 machines, when a memory manager like QEMM maps high
memory (UMB "upper memory blocks" (DOS 5.0 messed up the terminology,
so now "high" refers to HMA...leave it to Microsoft...)) for using
device drivers, it essentially pulls EMS memory down to map there, but
unlike memory in the EMS page frame, UMB memory is *never* paged out.
The processor's memory mapping lets you treat it just like regular DOS
memory, except that it's not contiguous with the base 640K so DOS
programs may have problems trying to use it directly.  That's where
the "loadhi" (DOS 5's loadhigh/lh/devicehigh) commands come in: they
put a device driver or other TSR program in a UMB.  If that program is
already infected, unless the virus has problems being loaded in a UMB
region, it can still take over, and in fact most drivers (and so
probably most .COM/.EXE infecting viruses) have no problem working
from a UMB just like they work when loaded low.

>handle it. You must use EMS memory driver to do so. Usually this memory is
>used for keeping huge amounts of data like spreadsheets. Some code may
>be placed there too. But it *MUST NOT* be a code which handles
>interrupts. Expanded memory is bankable, that is its total amount may
                                    ^^^^
Yes, when you're using EMS memory as EMS, it is paged into a "page
frame" by the EMS handler.  The full specification, however, allows
one to map EMS memory into any free space (possibly with the
constraint that that space be at segment A000 or higher, I'm not
certain)--if your EMS manager supports UMBs with EMS, it maps the EMS
memory down to the UMB, then *never*pages*it*out*.  The only areas of
memory one should expect to be volatile are video memory (if you've
got 256K of video memory or more, the board bank-switches it) and the
page frame.  Unless there's problems with the particular driver,
loading drivers into UMBs is safe and saves low memory.

>[stuff deleted]
>if you set interrupt address to code located in expanded memory, a
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^
Do you mean, "located in the page frame"?  Except in rare cases where
you have somehow turned EMS paging off (usually because you use the same
pool of memory as XMS and EMS, and are using it all as XMS at the
moment), putting code in the page frame is sheer insanity.

>[more deleted]
>If you have extended memory, that is a memory above 0FFFFh segment, you
>can use it only in protected mode of 80286/386/486 processor using
>their segment selectors mechanism. MS DOS runs in real processor mode,
>and you cannot reach code there via real mode's interrupt table.
True.

>[deleted]
>That's why I suggest that a code in high memory address space is not a
>malicious one.

One thing that I will agree that is if nothing is loaded high, it isn't
a virus, especially if you stopped things from loading high by axeing
the memory manager from your CONFIG.SYS.  A virus that's smart enough to
infect a .COM or .EXE that's also not too smart for itself in some way,
however, can easily be loaded high if it infects a TSR that you load
high.

>- -|- Vasili Bykov -|- Moscow -|- [e-mail] -|-

    Keith
([e-mail])
(Any opinions presented above can't possibly reflect the views of my
boss, since I don't think he even knows I get netnews...)

------------------------------

Date:    25 Jul 91 12:42:00 -0500
>From:    "William Walker C60223 x4570" <[e-mail]>
Subject: Viral Use of Memory Over 640K; Trust (PC)

>From:    [e-mail] (Vasili Bykov)
> []      In case of trivial PC without high memory the answer is *NO*,
>         surely.  For those machines anything you have above 0A000h
>         segment is either video data or some ROM routines. ...

The answer is "unlikely, but possible."  There are variants of the 512
and Doom-II viri (and maybe others) which put executable code into
video memory.  The problem with this method is that the code will get
overwritten the next time a program uses graphics.  Also, network
cards and devices like the HiCard, as well as EMS cards, put memory
between 0A000h and the ROM BIOS.  I think the MG-2 virus uses memory
here rather than video memory (I'm not sure -- it might use video).

Regarding use of expanded (EMS) and extended memory:
> ...You must use EMS memory driver to do so. ... Some code may be
> placed there too. But it *MUST NOT* be a code which handles
> interrupts. ... So if you set interrupt address to code located in
> expanded memory, a situation when an interrupt occurs but a bank
> where virus resides is switched off the memory space, will result in
> a system crash.  So expanded memory is not the best place for a
> virus.

> If you have extended memory, that is a memory above 0FFFFh segment,
> you can use it only in protected mode of 80286/386/486 processor
> using their segment selectors mechanism. MS DOS runs in real
> processor mode, and you cannot reach code there via real mode's
> interrupt table.

> Surely, some buffer code may be provided which resides in lower
> memory, catches interrupts, switches into protected mode or tells
> EMS driver to place bank with code into memory space, and gives
> control to virus itself.  But if you take into account that
> different computers have different high memory configuration, your
> virus should be extremely intelligent in order to work properly with
> any of them. A virus of size about 20 or 30 Kbytes is not the best
> one. It would not hide for long.

The part of the virus code residing in low memory would not have to be
large at all.  If the EMS driver (EMM.SYS or whatever) is loaded, the
interrupt handler could switch in the bank with the main virus code
and execute whatever it wanted.  I believe I've heard of a virus which
uses expanded memory.  I'm not sure about it, but I would appreciate a
more knowledgeable virus researcher saying whether or not there is one.

NORMALLY, the extended memory on an 80286/386/486 machine cannot be
reached when running in real mode.  HOWEVER, there is a cheat which
allows access to 65520 bytes (64K - 16 bytes) of extended memory just
above segment 10000h.  Microsoft capitalized on this cheat through
their HIMEM.SYS kludge and called it XMS (either eXtended Memory
Specification or eXtra Memory Specification -- I forget which).  I
don't think an interrupt could point there, but a low-memory interrupt
handler could pass control up there while remaining in real mode.  As
for switching to protected or another memory mode from real mode, the
problems involved in switching back and forth between modes would
probably keep a virus which does this from being "successful."

Also,
>From:    [e-mail] (Fritz Schneider)
> One problem that may occur is that of BIOS-shadowing. We can no
> longer assume that the BIOS is in ROM at the time that it is
> executed.  Many machines now copy it to faster RAM. It is possible
> that a virus might intercept the BIOS call inside the BIOS itself
> rather than in the interrupt table.

On the machines with which I've worked that have shadow-RAM, the
circuitry of the computer prevents writes to the shadowed BIOS, once
the ROM BIOS has been copied into it.  A virus would not be able to
modify the shadow-RAM.  This may not be true for all shadow-RAM
computers, but it should be.

- - - - - - - - - - - - - - - -
On a different subject,
>From:    [e-mail] (A. Padgett Peterson)
> ... a response was posted to another comment that you must boot
> cold from an infected floppy before trust is possible even if a
> clean Int 13 (disk access) path is known.

This has to be an unintentional faux pas on Padgett's part.  Trust is
possible only if you cold boot from a KNOWN CLEAN floppy.  I'm sure
that he would not intentionally write that -- at least he'd BETTER
not!  ;-)

Bill Walker ( [e-mail] ) |
OAO Corporation                        | "Non sequitur -- your facts are
Arnold Engineering Development Center  |  un-coordinated."
M.S. 120                               |           -- NOMAD
Arnold Air Force Base, TN  37389-9998  |

------------------------------

Date:    Thu, 25 Jul 91 19:23:06 +0000
>From:    [e-mail] (McAfee Associates)
Subject: Re: CARMEL TntVirus, A Trojan suspect. (PC)

[e-mail] ( Mr S. Rahim ) writes:
>I got hold of Carmel Antivirus package through a bulletin board. After
>having installed it on the harddisk two weeks ago, I began to have
>problems. This included EXE and COM files which were working before
>Carmel came on the PC.  Some files hang up while others refuse to run.

Carmel Software Turbo Anti Virus package is a commercial package.  If
you did not purchase your copy or otherwise receive it directly from
them, it could have a virus in it or otherwise be tampered.  TAV has
an "immunize" feature, if I recall correctly, that works by adding
virus marker bytes (the signatures that viruses use to see if a file
is infected) to the end of .COM and .EXE files.  It could be that the
files you immunized are self-checking and recognize that they have
been modified.

>When TntVirus is activated, I performed a scan of the memory with
>McAffee Scan V80, and it reported that P1 Related virus was active in
>memory. Another file relating to the package when run, SCAN revealed
>that Brain was active in memory.

[rest of message deleted...]

TntVirus apparently does not cipher its strings in memory or flush memory
after running.  This would account for the viruses found in memory.

Aryeh Goretsky
McAfee Associates Technical Support

- --
McAfee Associates     | Voice [phone]    | [e-mail]  (business)
4423 Cheeney Street     | FAX   [phone]    |
Santa Clara, California     | BBS   [phone]    | [e-mail](personal)
95054-0253  USA         | v.32  [phone]    |
ViruScan/CleanUp/VShield | HST   [phone] | CompuServe:  76702,1714

------------------------------

Date:    Thu, 25 Jul 91 19:04:49 +0000
>From:    [e-mail] (John Francis)
Subject: Re: Philosophy, comments & Re: long and technical (PC)

[e-mail] (A. Padgett Peterson) writes:
[ . . . ]
>    Back to the main subject, the question of authentication of a system
[ . . . ]
>    Given clean and authenticatable periperal paths, integrity
>programs and scanners can be run at any later time with the ability to
>bypass possibly untrustable elements thus rendering all currently
>known stealth techniques useless.
>
>    The authentication task may then be invoked at any time before
>or after the loading of the O/S with expectation of valid results
>being obtained.

I accept the validity of these statements.  I do not, however, accept your
belief that you can get "clean and authenticatable periperal paths" on a PC.

Yes, you could (hypothetically) save the BIOS vector adresses somewhere.
In fact the BIOS already has these - it has to initialize the vector table.
BUT - on 386 or better systems, I can write a "Virtual Machine" emulator
that can fool you into believing you are running on the raw hardware.
This means I can write the ultimate stealth system - undetectable by any
means whatsoever (not quite true, but I don't want to give everything away).
I can then build whatever else I want around this stealth system, protected
by the same disguise.  Any (yes, any) authentication task that was run once
my "Virtual Machine" virus took control would report the system to be virus
free.  That is a really scary thought.

------------------------------

Date:    Thu, 25 Jul 91 10:32:11 -0700
>From:    [e-mail] (Rob Slade)
Subject: Printer paranoia

Not virus related, but a good example of the odd thinking people get into
when dealing with computer security:

Our submission for the "Chicken Little" award for computer
advertising:

>From the July 8th edition of "Federal Computer Week", page 36:

    "The PS:Refillable Cartridge can be used with nearly

     all ... laser printers ... It is refillable by the

     user and never leaves the user's premises, insuring

     that data security is never compromised."

Laser printer toner cartridges do contain the printer drum.  On
laser toner cartridges the drum is 2 - 3 cm in diameter.  By
dint of extraordinary effort, you should be able to reconstruct
the last 1/3 of the last page to be printed ...

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Thu, 25 Jul 91 17:46:29 -0400
>From:    Andrew Brennan <[e-mail]>
Subject: Virus Scan V57 and V77. (PC)

      I've an interesting problem at the center I am working for.
   Apparently, SCAN stops checking memory for Stoned after V57.  We
   have V57 (in normal use) and can locate Stoned in memory, but it
   is not found on the disks - hard disks or otherwise.  After we
   reset the machine (booting from the hard disk), we have Stoned
   in memory again - not located on the hard disk.
      My immediate assumption was that it was a strain of Stoned
   that was not locatable by the old version - but the basic shape
   of Stoned was locatable in the memory of the machine.  Upon a
   boot from a clean disk, no Stoned anywhere.  I dug out a copy of
   V77 (assuming/hoping that it would locate the virus on the disk)
   only to find that V77 no longer memory-scans for Stoned.  I also
   found that V77 was unable to find Stoned on the same harddisk.
   We don't have V80 and I was unable to retrieve a copy via the
   Internet as there was/is some problem out there that was not
   allowing access outside this site - some server was down ...
      We tried (a suggestion from an outside source) optimizing the
   hard disk - to remove any phantom viral activities(?)  V57 still
   finds Stoned in memory - not on the disk.  V77 doesn't look for
   Stoned in the memory _and_ doesn't find it on the disk.  I will
   be retrieving a copy of V80 ASAP, but I don't know exactly what
   to think in this situation ...

      Andrew.  (brennaaa@duvm)  Drexel Univ.  College of Info Studies.

------------------------------

Date:    Fri, 26 Jul 91 10:22:39 +1200
>From:    Robert Davies <[e-mail]>
Subject: Re: F-PROT & DOS 5.0 (PC)

[e-mail] (Lou Anschuetz) writes:
>Installed DOS5.0 on my machine last night (which works well imho),
>but ran into a problem with F-PROT.  If I attempted to leave the
>F-PROT driver.sys in my config.sys file the machine would freeze
>and complain that INT13 was modified (undoubtedly true).  Has
>anyone found a work-around for this?
>
>Thanks in advance!
>
>Lou Anschuetz
>[e-mail]

Try shifting the location of the F-Prot driver.sys in your config.sys
file. I got the INT13 message when I first tried F-prot (the second to
most recent version - haven't upgraded yet) but it went away when I
moved the device statement to later in config.sys. It even loads into
high memory.

Robert

------------------------------

Date:    26 Jul 91 09:37:24 +1000
>From:    [e-mail]
Subject: New Jerusalem - Help! (PC)

My next-door neighbour has an Commodore Colt XT which has become
infected with a virus ("New Jerusalem").  The hard disc has been
treated with two virus removers, which identified the virus and
supposedly removed it, yet the system still crashes.  After
re-formatting the hard disc and copying fresh files from virus-free
backup discs the virus is still there.

What is the "New Jerusalem" virus,  what does it do,  and how do
you get rid of it?

Please send advice to "[e-mail]" and I will pass it on.

------------------------------

Date:    25 Jul 91 19:21:00 +0000
>From:    motcid![e-mail] (Craig Ibbotson)
Subject: Re: Anti-Virus software recommendation sought

[e-mail] (David Ivens) writes:

>We are considering purchasing a site licence for Virus Buster from
>Leprechaun Software.

>It looks a very good package.

>Any advice?

Byte magazine did a fairly good article on anti-virus programs
this month.  I don't know if they reviewed Virus Buster, but it
sounds familiar.  I would recommend you look there for a reference.

Overall, I believe they recommended ViruScan from MacAfee - this is
a shareware program.  I recently downloaded it and tried it myself -
I think it is very good and plan on sending in my registration.

- --
|Craig Ibbotson, Motorola, Inc.                 ...uunet!motcid!ibbotsonc|
|Cellular Infrastructure Division, Radio Telephone Systems Group         |
|"Is this the Big M - or are we becoming the Big A?"              |
==========================================================================

------------------------------

Date:    25 Jul 91 23:14:38 -0400
>From:    "Robert McClenon" <[e-mail]>
Subject: Terminology and Taxonomy

Terminology 2:  Bacteria

     At least two recent posts have suggested the use of the term
"bacterium" for some sort of malicious program.  (Fortunately at least
everyone agrees that the Emglish plural of this Latin noun is the
Latin plural "bacteria".)  Two posts have suggested exactly opposite
distinctions between viruses and bacteria.  Since the term "bacterium"
is not into mainstream usage and there is not agreement within the
computer security or anti-viral communities as to what it means, I
suggest that its use be avoided.  There is general technical agreement
so far that a code fragment that embeds itself in a program and
replicates by embedding itself in other programs is a virus.  If we
define boot records and similar automagically invoked resources as
programs, then we have a definition that encompasses everything that
computer security researchers normally refer to as viruses.  (In other
words, so-called viruses can be defined as viruses.)  I suggest we
drop any use of the term "bacteria", which merely confuses and
complicates, and focus on distinctions between types of viruses.

          Robert McClenon
          Neither my employer nor anyone else paid me to say this.

------------------------------

Date:    26 Jul 91 03:03:36 +0000
>From:    kddlab!lkbreth.foretune.co.jp![e-mail] (Robert J Woodhead)
Subject: Re: Revised Product Test- - Virex (Mac)

[e-mail] (Chris McDonald ASQNC-TWS-R-SO) writes:

>The  registration form received with the software gave one two
>options to obtain any future upgrades to the product.  The first option  was  a
>$75.00  Annual  Update  Service.   For  this  fee  Microcom  (then known as HJC
>Software) would provide automatic updates for a year.  The second option was to
>purchase  single updates for $15.00 upon notification of any VIREX new release.
>I chose the second option given  that  VIREX  at  version  2.0  identified  and
>repaired  all  known Macintosh viruses as of that time.  I wanted to build some
>historical knowledge as to the frequency with which updates might occur  before
>committing  myself  to the automatic annual fee.

A simple way to determine this is scroll down the opening intro info
that is displayed when you start the program.  At the bottom is a
detailed revision history for Virex -- and you can see that it has
in the past been updated more than 5 times a year.

This year has been slow -- and in this business, that's the kind
of year you want to have.

The other advantage of the auto-update is that it is faster; you get
the new disk as soon as possible, protecting you against a new virus
you might not have heard about yet.

Disclaimer : I'm the guy that Bob Capon of Microcom (then HJC) had
to beg to write the program.  I was sure that there wasn't a market
for it.  He called me every day for a month.  I finally did it to
get him to stop calling.

- --
+--------------------------------------------------------------------------+
| Robert J. Woodhead, Biar Games / AnimEigo, Incs.   [e-mail] |
| ``If you want to stab someone in the back, Bernard, you must first get   |
|   behind them!'' -- Sir Humphrey Appleby on the mechanics of politics.   |

------------------------------

Date:    25 Jul 91 23:13:32 -0400
>From:    "Robert McClenon" <[e-mail]>
Subject: Toward a Taxonomy of Malicious Programs

William Walker proposes, borrowing from Eldar A. Musaev, the following
taxonomy of malicious software:

>Malicious Program Definitions
>
>The functional criteria for classifying malicious programs are:
>I.   Replication
>     1.  Non-replicator
>         A program which does not copy itself.
>     2.  Dependent Replicator
>         A program which copies itself only when the host program
is
>         executed.
>     3.  Independent Replicator
>         A program that, once started (e.g. TSR), could copy
>itself
>         continuously without outside assistance.
>
>II.  Host Basis
>     1.  Standalone (non-host-based)
>         A program which does not require another program to help
>it
>         run and/or spread.
>     2.  Host-based
>         a.  Spawning
>             A program which leaves the host program intact, but
>runs
>             before the host program and calls or "spawns to" it.
>         b.  Overwriting
>             A program which overwrites a portion of the host
>program
>             or deletes and replaces it entirely, so that it is
>run
>             instead of the original program.
>         c.  Parasitic
>             A program which attaches itself to the host program,
>             leaving it functionally intact.

     This scheme is extremely useful as a first step toward defining a
taxonomy of viruses and other malicious software.  My only structural
criticism of it is that it is based on an exhaustive multiplicative
enumeration.  In other words, it is an N-dimensional array.  The
basic data structure of biological (e.g., Linnaean) taxonomy is a tree
rather than an array.  The empty slots in the array illustrate that
the array is not the best data structure.  (In biology, the types of
teeth often characterize mammals.  They never characterize reptiles,
which have undifferentiated teeth, or birds, which are generally
toothless.  The types of beaks sometimes characterize birds, but never
mammals.)

     Here is a very preliminary try at a tree-based taxonomy of
malicious software:

1.  Standalone Programs

1.1  Standalone Non-replicating Programs

1.1.1  Non-overwriting Trojans
     Ex:  ARC 5.1.3

1.1.2  Overwriting Trojans
     Ex:  Twelve Tricks

1.2  Standalone Replicators

1.2.1     Single-System Standalone Independent Replicators

     Ex:  WABBIT  (a prank at RPI which spawned multiple tasks
until it crashed the host).  Since WABBIT is the prime
representative of this taxon which depends on rapid reproduction,
I propose that they be generically called rabbits.

1.2.2     Multi-System Standalone Independent Replicators:  Worms
     Ex:  Morris Internet Worm

1.2.3     Multi-System Standalone User-Dependent Replicators:
Trojan Worms
     Ex:  CHRISTMA

2.   Host-Program-Dependent Programs

     (I think that all of these replicate, because otherwise they
are either not malicious or are standalone malicious programs.)

2.1  Media Infectors

2.1.1     Boot-Sector Infectors
     Ex:  Stoned

2.1.2     Media Resource Infectors
     Ex:  WDEF

2.2  Operating System Infectors
     Ex:  Lehigh

2.3  Application Infectors

2.3.1     Spawning Application Infectors
     Ex:  AIDS II, Twin-351

2.3.2     Overwriting Application Infectors
     Ex:  382 Recovery

2.3.3     Parasitic Application Infectors

2.3.3.1   Dependent Parasitic Application Infectors
     Ex:  Vienna

2.3.3.2   Semi-dependent Parasitic Application Infectors
     (These require invocation of an infected application to go TSR
but then continue to infect other applications.)
     Ex:  Jerusalem

     I suggest that this or a similar tree structure is the
appropriate way to categorize malicious software.  I admit that I
this list is not complete and that subcategories and occasionally
categories need to be added.  In particular, where should we put a
flip-flop virus like Tequila?  Is it 2.1.n+1, 2.3.n+1, or 2.4?

          Robert McClenon
          Neither my employer nor anyone else paid me to say this.

------------------------------

Date:    25 Jul 91 23:36:35 -0400
>From:    Kevin Dean <[e-mail]>
Subject: Re: Self-scanning executables (PC)

A friend of mine, Jeff Boyd ([e-mail]), pointed me to
this discussion when the subject of self-scanning executables came up
a few weeks ago.  Last year, I developed an anti-virus algorithm that
does a CRC check on the disk image of the running program.  This CRC
is stored within the executable itself, so in order to work, a set of
equations have to be solved to determine the original CRC.

Cracking the algorithm is not a trivial task: a virus has one chance
in four billion (2^32) of successfully infecting a program or, if it
decides to fool the algorithm by changing the stored CRC, would lock
up a 386 for hours bordering on days to find and change it.

The algorithm, supporting code, and supporting executables have all
been released to the public domain.  I have asked Jim Wright, the file
manager for VIRUS-L, to post it on the VIRUS-L server.  In the
meantime, if anyone would like a copy, drop me a note and I'll send
you the package in UU-encoded form.  If anyone would like to make it
available for FTP anywhere, drop me a note and I'll send it along.

- ---- Kevin Dean ----
[e-mail]
"If the implications aren't immediately obvious, don't ask."

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 131]
******************************************
VIRUS-L Digest   Monday, 29 Jul 1991    Volume 4 : Issue 132

Today's Topics:

Re: F-PROT configuration question (PC)
Re: F-PROT & DOS 5.0 (PC)
CARO and EICAR
Re: viruses in the press
Re: F-PROT & DOS 5.0 (PC)
Re: Index of Known Malware: 998 viruses/trojans
Re: F-PROT & DOS 5.0 (PC)
ScanV57 & Stoned alarm (PC)
Re: Self-scanning executables (PC)
Dark Avenger (PC)
Re: Virus Scan V57 and V77. (PC)
Index of Known Malware: 998 viruses/trojans
Re: HighMemory(even longer & more technical) (PC)
Re: Philosophy, comments & Re: longer and technicaller
Re: High Memory (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    26 Jul 91 08:01:08 +0000
>From:    [e-mail] (Fridrik Skulason)
Subject: Re: F-PROT configuration question (PC)

The configuration of F-PROT will change a bit with the soon-to-be released
version 2.0.

Instead of loading F-DRIVER.SYS from CONFIG.SYS and running F-NET.EXE after
the network software is loaded, the programs have now been combined into
one: VIRSTOP.EXE

This program is loaded from AUTOEXEC.BAT, so...

  (for)  On a network, a single copy can now be kept on the server, instead
        of having to update each individual machine, when a new version is
      released

 (against) F-DRIVER.SYS was more-or-less immune to infection, being a device
     driver, and it could prevent an infected COMMAND.COM from running.
    VIRSTOP.EXE may become infected, if it is run after an infected
    program.  It performs a very good self-test, however, so it will
    even detect an infection by a sophisticated "stealth" virus, such
    as Frodo.

I have just received a report of one strange conflict regarding
F-DRIVER/F-NET.  If run on a Novell network, with a certain version of
Netware, and the user is running Windows, and either Excel or Word for
Windows, and attempting to print to a laser printer, the output will
become garbled.  Switching to a copy of Netware, with a slightly
different size and date, but the same version number solved the
problem.  I don't have an explanation, but I would very much like to
hear from anyone else who encounters this problem.

- -frisk

------------------------------

Date:    26 Jul 91 08:03:46 +0000
>From:    [e-mail] (Fridrik Skulason)
Subject: Re: F-PROT & DOS 5.0 (PC)

[e-mail] (Lou Anschuetz) writes:
>Installed DOS5.0 on my machine last night (which works well imho),
>but ran into a problem with F-PROT.  If I attempted to leave the
>F-PROT driver.sys in my config.sys file the machine would freeze
>and complain that INT13 was modified (undoubtedly true).  Has
>anyone found a work-around for this?

There are three possible solutions, one of which should work on your
machine.

1) load F-DRIVER with DEVICEHIGH=
2) load F-DRIVER last in CONFIG.SYS
3) load F-DRIVER with DEVICE=F-DRIVER /NOINT
   (this undocumented switch disables the interrupt check).

- -frisk

------------------------------

Date:    Fri, 26 Jul 91 14:25:28 +0200
>From:    [e-mail]
Subject: CARO and EICAR

In "Der Aarbote" 1991-04-19, a local newpaper, the founding of two
anti-virus organizations was anounced. Here's a short excerpt from
this article (the original text isn't as clumsy as my translation
B-]):

"To avoid unneccessary double work, leading virus experts in europe
founded two international organizations: with CARO (Computer Antivirus
Research Organization), the scientists want to coordinate their
anti-virus-work; EICAR (European Institute for Computer Anti- Virus
Research) is the organization of the commercial software developpers.
CARO and EICAR will be located in Brussels. The most important goal is
to develop a common language to describe computer viruses and to
inform each other about new viruses".

I never read something about CARO and EICAR on this list. Does anyone
have some information about this two organizations or other
international efforts to fight computer viruses?

Christian Treber

`___'
/- -\  "Big brother is writing you!"
\ | /     [e-mail]
 \-/         Christian Treber, FRG, FH Fulda, FB Telecommunications

------------------------------

Date:    Fri, 26 Jul 91 02:27:40 -0500
>From:    Paul Coen <[e-mail]>
Subject: Re: viruses in the press

Well, all I can say is that in a document that I wrote for the Drew
University Academic Computer Center (and I think that the department
that hands out freshman computers included it in their fresman
handbook) started out by saying that you should forget what you've
heard about viruses from the press, since too much of it is
inaccurate.

Okay, we can't expect the press to be perfect.  We can expect them to
at least make an effort.  And in fields that I'm pretty well-versed
(computers, cultural & physical anthropology, sociology, etc.),
they're horribly inaccurate.  People I've talked to in other fields
have complained about reporting in their areas -- incorrect in ways
that shouldn't have happened if the person either writing or editing
the story had even taken an intro course in that field or a related
field.

I'd say that asking "people in the know" -- establishing contacts in
various fields would help, except that often times newspapers don't
even quote correctly, or attribute the quotes to the correct people.

An example: during the Morris worm incident, a reporter from the
Newark Star-Ledger in NJ called the Academic Computer Center, and
talked to my boss, his boss, and a student programmer about it.  We
all knew about it, because we'd read everything that had come in over
the net about it, so we told her what we knew.  My boss told her that
it wasn't a virus.  In her story, she called it a virus.  She then
went on to not use quotes from my boss (Neil) but from his boss (Bill)
but proceeded to attribute the quote to Neil.

Moral of the story: the press makes mistakes.  Okay, again, they're
human.  But if "journalists" can't report properly or put a reasonable
perpective on an event or topic, shouldn't papers and news
organizations be hiring more people who understand the technology AND
can communicate?  There are a few of us out here.  There are quite a
few on this list :).

If you're a journalism student, and want to pick a bone with me, go
ahead.  Just don't EVER write a factually incorrect story about
computers or anthropology in a paper I read :).
- ----------
Paul Coen -- [e-mail], [e-mail], [e-mail]
Disclaimer: These ARE my opinions -- I've been taking the summer off.

------------------------------

Date:    26 Jul 91 11:41:31 +0000
>From:    M I Clarkson <[e-mail]>
Subject: Re: F-PROT & DOS 5.0 (PC)

  I found problems with F-PROT's F-DRIVER.SYS and DOS 5.0 too.  The
cause of the problem on my machine seems to have been HIMEM.SYS.  It
modifies INT 13, doesn't it?  Anyway, try moving F-DRIVER.SYS to just
after HIMEM.SYS in your CONFIG.SYS file.  My machine now boots OK, and
traps F-TEST OK.

Mike.

------------------------------

Date:    26 Jul 91 21:09:49 +0000
>From:    [e-mail] (Shoou-yu tang)
Subject: Re: Index of Known Malware: 998 viruses/trojans

[e-mail] (Klaus Brunnstein) writes:
>VTC documents (Index of Known Malicious Software: IMSDOS.791; Index of Virus
>Catalog: Index.791; all entries classified up to now) are now available from
>FTP:
>         Our FTP server:  ftp.rz.informatik.uni-hamburg.de

 Does anyone has the Internet IP # for this site?
 Our system does not have a table link to this address and local name server
 can't find it too.
 Thanks
 Tang
 [e-mail]

[Ed. See follow-up below.]

------------------------------

Date:    Fri, 26 Jul 91 14:01:37 -0700
>From:    [e-mail] (Rob Slade)
Subject: Re: F-PROT & DOS 5.0 (PC)

[e-mail] (Lou Anschuetz) writes:

> Installed DOS5.0 on my machine last night (which works well imho),
> but ran into a problem with F-PROT.  If I attempted to leave the
> F-PROT driver.sys in my config.sys file the machine would freeze
> and complain that INT13 was modified (undoubtedly true).  Has
> anyone found a work-around for this?

I was able to find workarounds on two different machines.  On one,
booting off the A: drive, with a normal CONFIG.SYS, fixed the problem.
On a PS/2, this did not work.  I was able to get it too work by invoking
F-DRIVER.SYS after the HIMEM.SYS.

Other ideas about "loading high" did not seem to work in this case.  Here
is the relavent section of the CONFIG.SYS file:

rem devicehigh=c:\vir\fpr\f-driver.sys **hangs
rem device=c:\vir\fpr\f-driver.sys **hangs
rem device=c:\vir\fpr\f-driver.sys /noint **works
break=on
FILES=50
BUFFERS=32
LASTDRIVE=w
FCBS=16,8
shell=c:\command.com c:\ /p /e:1024
rem device=c:\vir\fpr\f-driver.sys **hangs
device=C:\dos\himem.sys
device=c:\vir\fpr\f-driver.sys
rem device=c:\dos\emm386.exe noems x=d000-d3ff
devicehigh=c:\dos\setver.exe
devicehigh=c:\dos\smartdrv.sys 2048 1024

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Sat, 27 Jul 91 09:40:14 -0400
>From:    Tom Young <[e-mail]>
Subject: ScanV57 & Stoned alarm (PC)

Andrew Brennan of Drexel writes:
>    I've an interesting problem at the center I am working for.
>   Apparently, SCAN stops checking memory for Stoned after V57.  We
>   have V57 (in normal use) and can locate Stoned in memory, but it
>   is not found on the disks - hard disks or otherwise.  After we
>   reset the machine (booting from the hard disk), we have Stoned
>   in memory again - not located on the hard disk.
>   ...

Are you perchance running AppleShare PC?  I seem to remember deciding
that the combination of ScanV57 and AppleShare 2.0 (but not 2.1?)
yielded a false positive for Stoned in memory.  This would also
explain why you don't get an alarm when booting from a clean diskette
(AShare stuff not loaded).  I never posted this tidbit since one or
both of the above versions of these products were outdated at the time
of my discovery :-).

Tom Young, Cornell Information Technologies, Workstation Systems Services
Bitnet: XMU@CORNELLA               Internet: [e-mail]

------------------------------

Date:    27 Jul 91 14:39:55 +0000
>From:    [e-mail] (Fridrik Skulason)
Subject: Re: Self-scanning executables (PC)

[e-mail] (Kevin Dean) writes:
>Cracking the algorithm is not a trivial task: a virus has one chance
>in four billion (2^32) of successfully infecting a program or, if it
>decides to fool the algorithm by changing the stored CRC, would lock
>up a 386 for hours bordering on days to find and change it.

Well, this is of just as much use as a simple checksumming algorithm -
it is very unlikely that a virus will attempt to atteck the encryption
algorithm itself - trying to "fake" the CRC.  A much more effective
method is to use "stealth" techniques.

If the implementation of this algorithm detects infection by Frodo
(4096), it is worth considering...

- -frisk

------------------------------

Date:    28 Jul 91 02:05:34 +0000
>From:    [e-mail] ([e-mail])
Subject: Dark Avenger (PC)

Hello,

I just discovered that my hard drive has been affected by the Dark
Avenger Virus.  I dutifully downloaded a few of the scanners and
disinfectants from wuarchives.  With the McAfee software (7.6v80), I
was told the the DA was there and then I used clean to remove it.
When I then run scan, it tells me all is well.  So, I power down and
reboot from my hard drive (having used a clean floppy before).  Now
scan tells me the the DA is present in memory again.

Am I doing something wrong?  missing a step?  Thanks for any help you
can give.

Pat

- --

Pat Sine                                         [e-mail]
Instructional Technology
Willard Hall Ed. Bldg., University of Delaware, Newark, DE 19716

------------------------------

Date:    Sun, 28 Jul 91 04:40:20 +0000
>From:    [e-mail] (McAfee Associates)
Subject: Re: Virus Scan V57 and V77. (PC)

[e-mail] (Andrew Brennan) writes:
>      I've an interesting problem at the center I am working for.
>   Apparently, SCAN stops checking memory for Stoned after V57.  We
>   have V57 (in normal use) and can locate Stoned in memory, but it
>   is not found on the disks - hard disks or otherwise.  After we
>   reset the machine (booting from the hard disk), we have Stoned
>   in memory again - not located on the hard disk.
>      My immediate assumption was that it was a strain of Stoned
>   that was not locatable by the old version - but the basic shape
>   of Stoned was locatable in the memory of the machine.  Upon a
>   boot from a clean disk, no Stoned anywhere.  I dug out a copy of
>   V77 (assuming/hoping that it would locate the virus on the disk)
>   only to find that V77 no longer memory-scans for Stoned.  I also
>   found that V77 was unable to find Stoned on the same harddisk.
>   We don't have V80 and I was unable to retrieve a copy via the
>   Internet as there was/is some problem out there that was not
>   allowing access outside this site - some server was down ...
>      We tried (a suggestion from an outside source) optimizing the
>   hard disk - to remove any phantom viral activities(?)  V57 still
>   finds Stoned in memory - not on the disk.  V77 doesn't look for
>   Stoned in the memory _and_ doesn't find it on the disk.  I will
>   be retrieving a copy of V80 ASAP, but I don't know exactly what
>   to think in this situation ...

To tell VIRUSCAN (also known as SCAN) to check memory for the Stoned
virus, add the "/M" parameter to the command line, i.e., SCAN C: /M
(and press Enter)

It could also be that you are having a false alarm with some other
program in memory, or that the disk optimizing program didn't erase
the "ghost" left over after disinfection.

You may wish to look at the partition table of the disk with a sector
editor to determine if the virus is there.  This would help rule out a
false alarm.

Regards,

Aryeh Goretsky
McAfee Associates Technical Support
- - - -
McAfee Associates     | Voice [phone]    | [e-mail]  (business)
4423 Cheeney Street     | FAX   [phone]    |
Santa Clara, California     | BBS   [phone]    | [e-mail](personal)
95054-0253  USA         | v.32  [phone]    |
ViruScan/CleanUp/VShield | HST   [phone] | CompuServe:  76702,1714

------------------------------

Date:    Sat, 27 Jul 91 22:14:02 +0700
>From:    [e-mail] (Morton Swimmer)
Subject: Index of Known Malware: 998 viruses/trojans

[e-mail] (Klaus Brunnstein) writes:

> Catalog: Index.791; all entries classified up to now) are now available from
> FTP:
>          Our FTP server:  ftp.rz.informatik.uni-hamburg.de
>          Login anonymous
>          ID as you wish (preferably your name)
>          dir: directory of available information
>          cd pub/virus: VTCs documents

Sorry, the address should have read:
    ftp.informatik.uni-hamburg.de

As the directory's moderator, I would ask everyone to first look for
the information at a site nearest you. We are very far off the
internet and suffer from a low load line (9600 BAUD) that is also used
for other things.

Cheers, Morton

[Ed. The DNS-registered IP numbers for this site are: 134.100.4.42 and
188.1.20.32.]

..............................................................................
.morton swimmer..odenwaldstr.9..2000 hamburg 20..germany..tel: [phone].
.internet: [e-mail] or [e-mail].
..............to leave only footprints, and take only memories................

------------------------------

Date:    Mon, 29 Jul 91 16:25:00 +1200
>From:    "Mark Aitchison, U of Canty; Physics" <[e-mail]>
Subject: Re: HighMemory(even longer & more technical) (PC)

[e-mail] (Keith Rohrer) writes:
> One thing that I will agree that is if nothing is loaded high, it isn't
> a virus, especially if you stopped things from loading high by axeing
> the memory manager from your CONFIG.SYS.

It is possible for a virus (admittedly, a pretty large virus) to be
loaded above A0000 even without one of the memory managers you
mentioned, but it does require certain hardware to be present. The
obvious way is to provide its own control of the 386 or Neat 286
chipset or even just the A20 line. But, since most people who buy such
hardware are hardly likely to have it without using such software to
get the best value out of it, such a virus is likely to conflict, and
the system would crash.  Also, a virus could try to live in the extra
RAM on a vidoe card (the Hercules card has plenty), or the RAM on some
network cards, etc... again, they would, in all probability, be
overwritten as soon as you use some programs, but it is theoretically
possible.

There are ways of checking that the code is ROM rather than RAM which
are easy to implement. I suggest that anyone tracing through memory
for a code segment greater than C000 should also check that it points
to ROM by trying to write something to it (with interrupts turned
off).

The machine I'm using now, for instance, has at least two chunks of
code up there grabbing the int 13 vector in addition to the BIOS.

Mark Aitchison.

------------------------------

Date:    Mon, 29 Jul 91 16:54:00 +1200
>From:    "Mark Aitchison, U of Canty; Physics" <[e-mail]>
Subject: Re: Philosophy, comments & Re: longer and technicaller

[e-mail] (John Francis) writes:
> BUT - on 386 or better systems, I can write a "Virtual Machine" emulator

I was hoping nobody would mention that possibility. It is a risk
saying too much, in case virus writers get ideas, but also a risk in
not alerting people to the possibility (e.g. I wonder if I should
*really* have mentioned that it is possible to get a virus from just
listing files in a directory?). Hopefully, that and the present idea
won't be too successful for virus writers, because they need a good
number of receptive systems to spread effectively.

For anyone worring about viruses taking advantage of 386 features,
here are a few thoughts to balance it with...

(1) Think of the size of the virus, what difference it would make to files or
disks it tries to infect - surely obvious even to uneducated users.
(2) Most people with a 386 will now be using MS- or DR-DOS 5 (or whatever) to
take adavantage of the hardware - such software at present might not be smart
enough to say "hey! there's a virus here already" but will probably crash.
(3) there are few ways of detecting it - especially when you know information
about the computer from the time it was virus-free. For one thing, exact
timings of some operations would be a big clue.
(4) if Microsoft, Digital Reasearch and others have any sense, THEY will use
the hardware to beat the viruses, instead of the other way around. Whoever -
virus writers or O/S writers, take control first and best, will win - or at
least make it extremely difficult for the opposition.
(5) I've run a checking program on a Sparc emulation of an AT, and noticed the
difference (I didn't even write the program with that system in mind) - any
virtual machine running under a 386 would be even easier to detect, given the
speed considerations - i.e. a 386 cannot emulate a 386 of the same clock speed
without making the extra time in hardware traps, etc obvious).

I said a long time ago that boot sector viruses are essentially
doomed; the ability to detect and stop* them will always be greater
than file viruses (given PC's of today and the near future). I may
have sounded very pessimistic about whether file viruses or anti-virus
measures will win in the long run (mainly because there are so many
programs that do just about the same things as a virus) - but really
good software in control of a 386 or better gives me, at least, a lot
of hope. Now come on, MS & DR guys! write it before the virus writers
use the loopholes, please!

Mark Aitchison.
* if you have more questions about a-v software beating *any* boot sector
virus, feel free to e-mail me.

------------------------------

Date:    Fri, 26 Jul 91 12:39:21 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: Re: High Memory (PC)

>From:    [e-mail] (Keith Rohrer)

>From:    "William Walker C60223 x4570" <[e-mail]>

Both writers make valid points concerning the "high memory areas"
available for DOS on modern (80286-up) platforms and the potential for
viral activity to use these areas. However, integrity management is
possible, even in this specialized environment.

The key is that at BIOS load time (before DOS), all Intel iapx80X86
processors are running in real mode (i.e. brain-dead as a 8086).
There should be no "high" or "extended" or "expanded" RAM available as
yet and all interrupts "should" be located in the segment range
C000h-F000h. This is easily authenticated with a fast pass through the
interrupt table since the segment prefix is in each vector. (the video
buffer A000h-BFFFh) is a data storage area and should not have
interrupts pointing there). While QEMM and others use the B000h-BFFFh
area in some cases for high menory, this does not occur until after
DOS & the memory manager loads. The only exception to this that I know
of is certain expanded memory boards designed for XT class machines
that incorporate the LIM page frame and use onboard ROM extenders for
access.

Since everything in this region is, in theory, ROM  and unwritable
(easily checked if necessary), verification is simple.

- ---------------------------------------------------------------
ANFSCD:

>From:    [e-mail] (A. Padgett Peterson)
> ... a response was posted to another comment that you must boot
> cold from an infected floppy before trust is possible even if a
               ^^^^^^^^
> clean Int 13 (disk access) path is known.

EEP! er, ah, that is...oops. Mr. Walker is of course entirely correct,
that should be "boot cold from an uninfected, write protected" floppy.

                        Padgett

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 132]
******************************************
VIRUS-L Digest   Wednesday, 31 Jul 1991    Volume 4 : Issue 133

Today's Topics:

Brunnstein (CARO) virus catalog files
Re: Exchanging floppies
Re: Philosophy, comments & Re: long and technical (PC)
Re: Virus Scan V57 and V77. (PC)
Dark Avenger (PC)
Tequila virus and partition table (PC)
Re: High Memory (PC)
Multi-compress
virues in io.sys (PC)
Re: Self-scanning executables (PC)
Observation on F-DRIVER.SYS & Windows 3 (PC)
CARO and EICAR
Re: Philosophy, comments & Re: long and technical (PC)
Re: Self-scanning executables (PC)
Related Terms

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Mon, 29 Jul 91 16:32:27 -0400
>From:    Kenneth R. van Wyk <[e-mail]>
Subject: Brunnstein (CARO) virus catalog files

The files which Dr. Brunnstein announced on 24 July 1991, along with
the rest of the virus information files from CARO, are now available
on cert.sei.cmu.edu (IP number 192.88.209.5) in the
pub/virus-l/docs/brunnstein directory.  Please use this archive rather
than ftp.informatik.uni-hamburg.de in order to limit the network load
to that site.

My thanks to the folks at CARO for making this excellent work freely
available.

Ken

Kenneth R. van Wyk
Moderator VIRUS-L/comp.virus
Technical Coordinator, Computer Emergency Response Team
Software Engineering Institute
Carnegie Mellon University
[e-mail]  (work)
[e-mail]   (home)
[phone]  (CERT 24 hour hotline)

------------------------------

Date:    Mon, 29 Jul 91 17:37:42 -0400
>From:    Peter Jones <[e-mail]>
Subject: Re: Exchanging floppies

On Thu, 11 Jul 91 11:24:58 -0400 you said:
>I work in a library in which we have been accepting disks from patrons
>in exchange for a formatted disk.  They then use those in our CD-ROM
>workstations to download.  We re-format the disks we receive to use in
>the exchange process.  To date, we have not had any infections
>(acording to virscan and f-prot).  My question is this: would we be
>better off zapping the disks in the demagnitizer, then formatting?  Or

I think formatting is enough. However, zapping is a great way to let
people know the data are going to be zapped forever. Also, you avoid
the problem of a disk slipping past the formatting station without
really being re-formatted (if someone is in a hurry and doesn't want
to wait for re-formatting).

Note that there are high-speed programs for copying/formatting a large
number of disks.

De-gaussing is also necessary if a DD disk has been accidentally
as HD, and you need to format at 2D on an HD drive.

Peter Jones                    (514)-987-3542
Internet:Peter Jones <[e-mail]>
UUCP: ...psuvax1!uqam.bitnet!maint
N.B.
"Our customers will forgive a one-time error far more quickly than they will
forgive our inability to correct that error." - Karen Ward ([e-mail])

------------------------------

Date:    29 Jul 91 19:28:20 +0000
>From:    [e-mail] (Wm E Davidsen Jr)
Subject: Re: Philosophy, comments & Re: long and technical (PC)

[e-mail] writes:

| One problem that may occur is that of BIOS-shadowing. We can no longer
| assume that the BIOS is in ROM at the time that it is executed. Many
| machines now copy it to faster RAM. It is possible that a virus might
| intercept the BIOS call inside the BIOS itself rather than in the
| interrupt table.

  Which braindead machines do that? I know about BIOS shadowing, but I
don't think I've ever found one which didn't set write protect so memory
maps would think it was ROM.
- --
bill davidsen    ([e-mail] -or- uunet!crdgw1!crdos1!davidsen)
  GE Corp R&D Center, Information Systems Operation, tech support group
  Moderator comp.binaries.ibm.pc and 386-users digest.

------------------------------

Date:    29 Jul 91 16:15:46 +0000
>From:    motcid![e-mail] (Bill Dyer)
Subject: Re: Virus Scan V57 and V77. (PC)

[e-mail] (Andrew Brennan) writes:

>   Stoned in the memory _and_ doesn't find it on the disk.  I will
>   be retrieving a copy of V80 ASAP, but I don't know exactly what
>   to think in this situation ...
>
>      Andrew.  (brennaaa@duvm)  Drexel Univ.  College of Info Studies.

My version of SCAN (V77) found Stoned on my hard disk, no problem.  It
was in the partition table.  I would check your version of SCAN to
make sure it is clean.  There was talk of a trojan version of SCAN,
but this was supposedly SCAN V78.  If you have a program that will let
you look at the disk (PCTOOLS or Norton), look at your partition table
or boot sector.  If you have Stoned, you should see the string "You
have been Stoned" or something like that.  At least I did when I was
infected.

While I am here, a question about Stoned.  From what I can tell,
Stoned is a memory resident program that resides in the partition
table on hard disks and the boot sector on floppies.  My question is
what triggers the thing to infect a floppy from the hard disk?  In
other words, what interupt is it stealing?  Second question, can
Stoned infect other places besides the partition table?  We have a PC
board plugged into one of our suns here at work, and I think the thing
is infected with Stoned.  However, the thing does not have a standard
hard drive, I think it uses NFS and a partition on the Sun's hard
drive.  The disk does not seem to have a partition table or a boot
sector that I can find?  Does anyone know how these PC boards in a Sun
work, and if it would be possible for Stoned to infect one of them.
Thanks for any help.

- -Bill Dyer
- --
_____________________________________________________________________________
|  I wish I could sit on soft pillows,      |Bill Dyer  [phone]      |
|  and eat molten lava.                     | [e-mail]      |
|                     -King Missle          | or  uunet!motcid!dyer         |

------------------------------

Date:    30 Jul 91 02:11:54 +0000
>From:    [e-mail] (Stefan Kozlowski)
Subject: Dark Avenger (PC)

Folks,
    A friend of mine just called me and asked for help with
removing the Dark Avenger virus from his PC. I know nothing about the
virus and little about PC's. Any information would be greatly
appreciated.

Thanks in advance.

- --Stefan Kozlowski
  MIT AI Lab
  [e-mail]

------------------------------

Date:    30 Jul 91 05:03:40 +0000
>From:    Lachlan Brown <[e-mail]>
Subject: Tequila virus and partition table (PC)

A friend of mine who works in a computer shop has recently had a
number of people coming to him with the Tequila virus on their systems.

In case I have a nasty encounter with it I'd like to know a little more.

If I understand correctly, the virus writes it's self in to the partition
table (as well as exe files and some other area of the hard disk)

Where exactly is the partition table? and is it changed or over
written in the a normal day on the computer, or can you back it up
using debug or whatevero in case some nasty groobly gets into it ?

 Thanks in advance
   Lachlan Brown
    The University of Queensland
    Electrical Engineering

------------------------------

Date:    30 Jul 91 10:44:00 -0500
>From:    "William Walker C60223 x4570" <[e-mail]>
Subject: Re: High Memory (PC)

>From:    [e-mail] (A. Padgett Peterson)

> The key is that at BIOS load time (before DOS), all Intel iapx80X86
> processors are running in real mode (i.e. brain-dead as a 8086).

Yep.

> There should be no "high" or "extended" or "expanded" RAM available
> as yet and all interrupts "should" be located in the segment range
> C000h-F000h. This is easily authenticated with a fast pass through
> the interrupt table since the segment prefix is in each vector. (the
> video buffer A000h-BFFFh) is a data storage area and should not have
> interrupts pointing there).

You cannot look only at the segment prefix to determine where the
vector points; you must calculate the actual address.  For example, if
you found the segment 9800h, you might assume that the vector pointed
into the top of the 640K RAM area.  But if the offset was 8000h,
making the entire address 9800:8000h, it would point to absolute
address 0A0000h, or the beginning of the video buffer.  True, there
should be no vectors pointing into any RAM, video or otherwise, before
DOS is loaded.  However, there is a more subtle example.

There is a portion of extended memory on a '286 or '386, which
Microsoft calls the High Memory Area (HMA), which is accessible from
real mode.  A good explanation of how it works is given in the article
"Power Programming" by Ray Duncan, in the June 27, 1989 issue of PC
Magazine, part of which I've quoted below:

> "Recall the method by which physical addresses are generated in real
> mode.  The contents of a segment register are shifted left 4 bits
> and added to a 16-bit offset.  On an 8086/88 machine, if the result
> overflows the 20-bit addresses supported by the CPU, the address
> simply wraps--that is, the upper bits are discarded.  80286- and
> 80386-based PCs can support larger physical addresses (24 bits and
> 32 bits, respectively), but this capability is ordinarily not
> apparent when DOS is running.  That's because these machines have
> special hardware to disable the most-significant address lines in
> real mode, making the machine behave more like an 8088.

> "Consider what happens, however, on an 80286 when you enable the A20
> line and place the value FFFFh in one of the segment registers.
> Enabling the A20 line allows the generation of 21-bit physical
> addresses.  And when FFFFh is shifted left 4 bits and added to a
> 16-bit offset, the result will fall in the address range FFFF0h-
> 10FFEFh.  In other words, enabling the A20 line allows the first
> 65,520 bytes of extended memory to be addressed WITHOUT LEAVING REAL
> MODE."  [my emphasis - WWW]

> - Duncan, Ray.  Power programming.  PC Magazine, V8 I12 (June 27,
>   1989), p. 321.  Copyright Ziff-Davis Publishing Co. 1989

Knowing this, suppose a virus has somehow infected a machine with a
pre-DOS validator, relocating it as though it was a normal boot sector
or MBR.  Also suppose that it has enabled the A20 line and stored part
or all of itself in the HMA, with vectors pointing up there.  These
vectors would by necessity have a segment prefix greater than 0F000h.
Now, when the validator gets control, it would mistakenly believe that
those vectors pointed into ROM below the 1M line if it only examined
the segment prefix.  But if it calculated the full absolute addresses,
it would easily see that the vectors pointed into the HMA, not ROM.

Such a virus, though possible, would not be very viable, since running
HIMEM.SYS or anything which used memory in protected mode would wipe
out the virus code in the HMA.  And, if the virus somehow protected
itself, these programs would bomb out, giving the user a clue that
something was wrong.

One other item:  there is a device I mentioned in a previous posting
called the HIcard from RYBS Electronics.  I'm not completely familiar
with this device, but I believe it adds 64K to conventional memory,
making a total of 704K.  I believe it also puts that memory in an
unused block between 0A000h and 0F000h.  At first, it seems like a
device few people would use, but it is mandatory on 8086/88/286
systems to run dBASE IV 1.0 with most networks, so there could be
quite a few in use.  And there's nothing to prevent a virus from using
it at any time, even before DOS loads......

Disclaimer:  The quoted material from A. Padgett Peterson belongs to
  him.  The quoted material from PC Magazine belongs to Ziff-Davis
  Publishing.  The rest belongs to me.  None of it belongs to my
  employer.

Bill Walker ( [e-mail] ) |
OAO Corporation                        |   "... but as we say on Earth,
Arnold Engineering Development Center  |          c'est la vie."
M.S. 120                               |        - James T. Kirk
Arnold Air Force Base, TN  37389-9998  |

------------------------------

Date:    Tue, 30 Jul 91 10:19:00 -0700
>From:    [e-mail]
Subject: Multi-compress

Dmitri Schoeman   in VIRUS-L #129:
> If the "compressed" code is larger than the original code it will
> erase the temp file, and I am sure we are all aware of the
> non-permancy of the erase command,.....

Ah, so /that's/ it.

Good going, Dmitri... this is a point that had eluded me since I
generaly do my compressions in a RAM disk for speed.

Perhaps we can prevail upon the makers of such to do a WIPE olike
routine on the old files to prevent this kind of thing?

> Can anyone verify if the code is sufficiently changed by the above
> method?

In the method you describe, the code being changed isn;t the problem,
here; it's that the checkers such as SCAN won't look inside a nested
file. It would look at the first level, without de-compressing the
file inside, and therefore wouldn;t see a virus inside the nested
file.

Again, seems the only way to prevent this is to tamper proof the
PKLITE and LZEXE code.... Again, perhaps if we yelled loud enough...

I'm quite sure Phil Katz would at least be interested in such a proposal.

And another good idea is Padgett's..>>>.The answer, of course, is for
scanners to use a recursive technique for unravelling files and it
would be relatively easy to check. Eternal Vigilance and all that.  <<
Perhaps both ideas are worth pursuing?

------------------------------

Date:    30 Jul 91 14:09:15 +0000
>From:    [e-mail] (Willi Grueber)
Subject: virues in io.sys (PC)

Ares there any viruses infecting io.sys and thus installing themselves
before DOS is started ?

Which virus-scanners check for infected io.sys files ?

Thanks
    Hermann

[e-mail]

------------------------------

Date:    Tue, 30 Jul 91 17:56:16 +0000
>From:    [e-mail] (John Francis)
Subject: Re: Self-scanning executables (PC)

Somewhere on CompuServe, Kevin Dean writes:
> Cracking the algorithm is not a trivial task: a virus has one chance
> in four billion (2^32) of successfully infecting a program or, if it
> decides to fool the algorithm by changing the stored CRC, would lock
> up a 386 for hours bordering on days to find and change it.

Unfortunately this is nothing more than "Ignorance Protection".  There
has to be some way of calculating the initial CRC when the program is
built - they don't appear in the executable by magic!  This must be by
some method that is faster than exhaustive search, or else nobody will
use CRC protection. The same algorithms are available to virus
writers.

It won't take long to find the encryption code in an executable - the
techniques to do that can be found in all the current virus scanners,
and we must assume that most virus writers are conversant with these
methods, and could use them themselves to find the right spot.

------------------------------

Date:    Tue, 30 Jul 91 15:47:37 -0600
>From:    [e-mail] (Richard W Travsky)
Subject: Observation on F-DRIVER.SYS & Windows 3 (PC)

I was recently given a Zenith 386 to use here at work.  These come
pre-installed with Windows 3.0 and DOS 4.01.  I had troubles getting
Windows to come up in enhanced mode.  It would default to standard and
on startup would complain about not finding an application (when it
should not have even been looking for one in the first place).  The
program manager window was small (not minimized, more like a window
onto a maximized window - hopefully you get the picture).  And there
was a couple of other minor annoyances I've already forgotten about.

Any,  I played the windows game,  fiddling with my config.sys.  What
worked was moving F-DRIVER.SYS towards the end of the device calls.
Anyone have any other Windows/fprot experiences?  After the recent
posts about F-DRIVER.SYS and DOS 5.0 I thought it interesting enough
to pass on.

Richard Travsky
Division of Information Technology     RTRAVSKY @ CORRAL.UWYO.EDU
University of Wyoming                  (307) 766 - 3663 / 3668

------------------------------

Date:    Tue, 30 Jul 91 09:42:15 -0700
>From:    [e-mail] (Rob Slade)
Subject: CARO and EICAR

[e-mail] writes:

> I never read something about CARO and EICAR on this list. Does anyone
> have some information about this two organizations or other
> international efforts to fight computer viruses?

CARO is connected with Klaus Brunnstein, the primary contact for the
Computer Virus Catalogue project, and a fairly regular contributor.

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Fri, 26 Jul 91 17:08:44 +0000
>From:    [e-mail] (Martijn Nykerk)
Subject: Re: Philosophy, comments & Re: long and technical (PC)

Maybe a Followup WILL make it out of here.

Anyways [e-mail] (John Francis) opposing [e-mail]
(A. Padgett Peterson) on authenticatable peripheral paths writes:

>  I do not, however, accept your belief that you can get clean and
>  authenticatable periperal paths" on a PC.

>  On 386 or better systems, I can write a "Virtual Machine" emulator
>  that can fool you into believing you are running on the raw hardware.
>  This means I can write the ultimate stealth system - undetectable by any
>  means whatsoever (not quite true, but I don't want to give everything away).

I don't want to give everything away?  (are you working on one? :) ;) :)    )

Forgive me if I am wrong but wouldn't the check to see if you're at
ROM BIOS (if that's where you want to be) be just a memory write and a
check to see if your byte survived in the big world?  Ofcourse
shadowing would sort of f*ck this check up I guess.

Martijn.

------------------------------

Date:    Mon, 29 Jul 91 13:05:00 -0400
>From:    Jeff Boyd <[e-mail]>
Subject: Re: Self-scanning executables (PC)

Fridrik Skulason <[e-mail]> wrote:
>  Well, this is of just as much use as a simple checksumming algorithm -

You either overlook or underestimate the value of it. When I write PC
software for sale or otherwise, I build this routine in and the
program has an INDEPENDENT self-check CRC calculation. My program will
not run if altered, and hence will NEVER aid in the spread of a virus
(provided the user takes appropriate cleansing action when the program
finds any changes - the virus could certainly move in the single run
required to expose its presence).

------------------------------

Date:    Fri, 26 Jul 91 14:13:25 -0700
>From:    [e-mail] (Rob Slade)
Subject: Related Terms

DEFGEN4.CVP   910721

                   Related (non-viral) terms

Two other groups of security breaking programs are very often
confused with viri.  The first is the "trojan horse", the second
the "logic bomb."  The confusion is understandable, as viral
type programs, trojan horses and logic bombs make up the three
largest distinct groups of security breaking software, and often
one may "contain" the code of one another.

A trojan horse is a program which pretends to do one thing,
while performing another, unwanted action.  The extent of the
"pretence" may vary greatly.  Many of the early PC trojans
relied merely on the filename and a description on a bulletin
board.  "Login" trojans, popular among university student
mainframe users, will mimic the screen display and prompts of
the normal login program, and may, in fact, pass the username
and password along to the valid login program, as well as
stealing it.  Some trojans may contain actual code which does
what it is supposed to be doing, while performing additional
nasty acts that it does not tell you about.  (I make the
distinction that trojans are always malicious, as opposed to
"joke" or "prank" programs.)

(A recent example of a trojan is the "AIDS Information Disk",
often incorrectly indentified in both the general and computer
trade press as a virus.  Not to be confused with the, fairly
rare, AIDS I and II viri, this program appears to have been part
of a well organized extortion attempt.  The "evaluation disks"
were shipped to medical organizations in England and Europe,
with covers, documentation and license agreements just like any
real commercial product.  When installed and run, it did give
information and an evaluation of the subject's risk of getting
AIDS, but it also modified the boot sequence so that after 90
reboots of the computer all files on the disk were encrypted.
The user was informed that, in order to get the decryption key,
a "license fee" had to be paid.)

Trojan horse programs are sometimes referred to as an "Arf, arf"
or "Gotcha" program from the screen messages of one of the first
examples.  A trojan horse may be used to plant a virus simply by
infecting any existing program.

A logic bomb is a malicious program which is triggered by a
certain event or situation.  Logic bomb code may be part of a
regular program, or set of programs, and not activate when first
run, thus having some of the features of a trojan.  The trigger
can be any event that can be detected by software, such as a
date, username, CPU id, account name, or the presence or absence
of a certain file.  Viral programs and trojans may contain logic
bombs.

copyright Robert M. Slade, 1991   DEFGEN4.CVP   910721

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 133]
******************************************
VIRUS-L Digest   Thursday,  1 Aug 1991    Volume 4 : Issue 134

Today's Topics:

Re: Virus for Sale
F-PROT and FluShot+ questions (PC)
**Virus Warning** Oracle DDE/Toolbox disk (PC)
Re: High Memory (PC)
Re: Self-scanning executables (PC)
Re: Self-scanning executables (PC)
CARO Computer Virus Index
VSUM - latest verion? where to get? (PC)
Partition tables have serial #'s in DOS 4.0 and 5.0?
Computer operations and viral operations
Call for Papers - IFIP/SEC '92

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    29 Jul 91 13:57:55 +0000
>From:    [e-mail] (Warren Burstein)
Subject: Re: Virus for Sale

[e-mail] (Rob Slade) writes:
>And what about the question of copyright?  :-)

Yeah, wouldn't you just love to see the author stick his head out of
the sewer.  Hmm, how about some work to expose the authors of these
things, like sending infiltrators into pirate BBS's, clubs, whatever.
If anyone has any leads in Israel, count me in.

- --
/|/-\/-\       The entire world            Jerusalem
 |__/__/_/     is a very strange carrot
 |warren@      But the farmer
/ worlds.COM   is not worried at all.

------------------------------

Date:    Tue, 30 Jul 91 19:47:30 -0500
>From:    tosspot![e-mail] (Lee Reynolds)
Subject: F-PROT and FluShot+ questions (PC)

Greetings, all.

I've been playing around with antiviral packages recently (for a few
years, really) and I'd like to know what other folk's views are of the
pros and cons of F-Prot and FluShot+.  I find that Flushot appears to
a few additional features to prevent ye fiendish virus from subverting
itself whereas F-Prot seems to be a tad more multifaceted than FS.

OTOH, I find that there is a small (but noticeable) overhead in keeping
F-Prot around.

Comments?

                         Lee

------------------------------

Date:    Wed, 31 Jul 91 15:11:06 +0000
>From:    [e-mail] (Sam Daniel)
Subject: **Virus Warning** Oracle DDE/Toolbox disk (PC)

We were recently sent a copy of Oracle's demo disk for their new
Windows' DDE/Toolbox.

The disk came pre-infected with the Stoned virus, which was caught by
our McAfee virus checker before it could do any damage.

Oracle is trying to reach all known recipients of the disk by
telephone, and is going to mail replacements as soon as possible.

[Ed. I verified this with some folks at Oracle.  They said that they
had indeed phoned all known recipients and that they had Federal
Expressed (overnight mail) the new disks to all (800 some)
recipients.]

- --
*
*
Sam Daniel          *   UUCP (Smart):  [e-mail]
Unisys              *         (Dumb):  {...}!uunet!netcom!daniel
500 Macara Ave.     *          Voice:  1-408-737-8000
Sunnyvale, CA 95131 *     Disclaimer:  Your mileage may vary...

------------------------------

Date:    Wed, 31 Jul 91 11:19:24 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: Re: High Memory (PC)

>From:    "William Walker C60223 x4570" <[e-mail]>

Mr. Walker brings up two points that relate to the ability to validate
ROM addresses at BIOS load time.

>You cannot look only at the segment prefix to determine where the
>vector points; you must calculate the actual address.

>There is a portion of extended memory on a '286 or '386, which
>Microsoft calls the High Memory Area (HMA), which is accessible from
>real mode.

This is true within certain limits, however the segment prefix specifies
the 64k contiguous segment that follows. With a segment address of F000h
NONE of the HMA can be reached since the upper limit of addressing from
this point is F000:FFFFh. In order to make the 64k less 10h bytes HMA
available, normally a segment prefix of FFFFh is used.

Since the BIOSes I have seen define the BIOS ROM vectors as
F000:xxxxh, a test for the range C000h to F000h (not FFFFh) would seem
to be a valid check. Please remember that this is being done before
DOS (or any other OS) loads.

>called the HIcard from RYBS Electronics.  I'm not completely familiar
>with this device, but I believe it adds 64K to conventional memory,
>making a total of 704K.

I am also not familiar with this particular card however the "adds
64k" part sounds like it creates a memory page frame for RAM expansion
for DOS to use similar to the expanded memory boards that I mentioned.
In that case I would suspect that there are jumpers on the board that
can be set to define the memory segment to be used (typically either
the D000h or E000h segment). There is no reason why an intelligent
software package could not be told that this area is also RAM.
(Read/Write a byte from each even segment would do it as Martijn
Nykerk suggested if the software has not "locked" that segment).

You must remember that DOS will accept any address in the 0000:0000h
to FFFF:FFFFh range as valid and is a constraint imposed by Intel on
the original iapx8086. If Intel had chosen to make the segment
granularity 100h bytes instead of 10h, DOS would have had 16 MB to
play with (but still in 64k "chunks"). The one true answer would have
been direct 32 bit addressing used as by Motorola for the 68000 (how
does Apple make it run so slow ? - gratuitous dig 8*) but in 1980, 1
MB of address space was a great leap forward from the 64k available
with Z80s & 6800s.

The key is that at BIOS time, interrupt vercors should point only to
non-volatile memory. Mr. Walker is correct in suggesting that this
point is a possible intrusion vector if RAM should be located in this
range. However, in practise and at present I would be satified to just
check the interrupt vector segment prefix. (am an engineer, not a
scientist).

Of course, there is not reason that the BIOS validation software could
not report all interrupts not possesing a F000h segment prefix and
display their signature block.

>Anyways [e-mail] (John Francis) opposing [e-mail]
m
>(A. Padgett Peterson) on authenticatable peripheral paths writes:
>  On 386 or better systems, I can write a "Virtual Machine" emulator
>  that can fool you into believing you are running on the raw hardware.
>  This means I can write the ultimate stealth system - undetectable by any
>  means whatsoever (not quite true, but I don't want to give everything away).

Sure you can - essentially this is what an OS/2 DOS "box" or Window's
Window or Soft ICE is - however, first you would have to gain control,
load the VM emulator, and invoke the "box". Not only is this going to
use a considerable amount of memory, but if it works properly (and
even MicroSoft has trouble doing this), it will probably not fit on a
360k disk

                        Padgett

------------------------------

Date:    Wed, 31 Jul 91 11:19:24 -0400
>From:    Padgett Peterson <[e-mail]>
Subject: Re: Self-scanning executables (PC)

>From:    Jeff Boyd <[e-mail]>

>You either overlook or underestimate the value of it. When I write PC
>software for sale or otherwise, I build this routine in and the
>program has an INDEPENDENT self-check CRC calculation. My program will
>not run if altered, and hence will NEVER aid in the spread of a virus.

Unfortunately, a "stealth" virus will defeat this method every time
(not to say it is not a good idea, I use something similar at home,
just insufficient without system integrity checking). This class of
malicious software simply presents the checksum routine with the
original, uninfected program.  Since the routine only "sees" the
program as it was, not as it is, the routine passes. Try it against a
resident 4096 infection for example.

However the technique will be effective against Jerusalem or Sunday
type infections in detecting that your program **has been** altered.

                    Padgett

"Never Say Never Again" from the movie of the same name. Based on an
interesting comma in an Ian Fleming novel.

------------------------------

Date:    Wed, 31 Jul 91 09:24:26 -0700
>From:    [e-mail]
Subject: Re: Self-scanning executables (PC)

In comp.virus, [e-mail] (John Francis) writes:

>Somewhere on CompuServe, Kevin Dean writes:
>> Cracking the algorithm is not a trivial task: a virus has one chance
>> in four billion (2^32) of successfully infecting a program or, if it
>> decides to fool the algorithm by changing the stored CRC, would lock
>> up a 386 for hours bordering on days to find and change it.

>Unfortunately this is nothing more than "Ignorance Protection".  There
>has to be some way of calculating the initial CRC when the program is
>built - they don't appear in the executable by magic!  This must be by
>some method that is faster than exhaustive search, or else nobody will
>use CRC protection. The same algorithms are available to virus
>writers.

>It won't take long to find the encryption code in an executable - the
>techniques to do that can be found in all the current virus scanners,
>and we must assume that most virus writers are conversant with these
>methods, and could use them themselves to find the right spot.

Most CRC checkers don't know where the CRC itself is, so there is a
little more security than just Ignorance Protection (called Security
Through Obscurity, or STO in alt.security), so an infector might break
the program.  If I disassembled/debuged some of the CRC checkers, _I_
probably could write a virus which checked for (some variants) of
those checkers and modified its infections accordingly; if I didn't
have source for the CRC generator, I might find it a difficult
mathematical problem to solve for the values to place in memory.
(Validation using a public key signature scheme?)

- --
[e-mail] [e-mail] [e-mail] (personal)
[e-mail] (work)
My opinions are my own, and do not represent those of my employer.

------------------------------

Date:    Wed, 31 Jul 91 13:05:37 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: CARO Computer Virus Index

    Just a couple of notes on the index since it is very valuable
information but is not what might be expected.

    Lately, I have been seeing quite a few "novice" postings that
by the wording indicate that the poster is not entirely familiar with
either the O/S involved or with viruses in general. This is a
dangerous situation since viruses are often spread by well-meaning
individuals who do not fully understand what they are dealing with.
For these people, some back ground is necessary.

    For a start, I would suggest Ray Duncan's "Advanced MS-DOS" as
a good primer. However, coming from MicroSoft press, as might be
expected there are a few omissions. The can be remedied with the QUE
book "Programmer's Guide to MS-DOS". Understanding salient parts of
these should be a pre-requisite, otherwise there is going to be a
language gap.

    The CARO index itself is not a single document, rather it is
split into a number of ASCII files of under 100k each. The MSDOS virus
section is at present made up of eight files, all with the name
MSDOSVIR.xxx. ALL eight are necessary for a complete index. Similar
file groups are used for AMIGA and MAC listings.

    Once retrieved, the most current file (now MSDOSVIR.791) can
be used to find individual elements from the listing in the front of
the file. The suffix for the file each entry is found in is the final
element on each line. (e.g. STONED is found in MSDOSVIR.290).

    A final note, it looks as if CARO is maintaining its files on
an IBM mainframe, at least the listings are in EBCDIC order. Look for
entries having numerical names (e.g. 4096) at the end of the listing,
not at the beginning.

                        Padgett

------------------------------

Date:    31 Jul 91 17:26:04 +0000
>From:    [e-mail] (mark r rauschkolb)
Subject: VSUM - latest verion? where to get? (PC)

How often does Patricia Hoffman release new versions of VSUM?

I remember seeing something about a new version with a new
user interface, but I cannot find one newer than March 91.

What is the newest version and where can I get it (via ftp)?

mark
[e-mail]

------------------------------

Date:    Wed, 31 Jul 91 19:24:35 +0000
>From:    [e-mail] (Glenn Forbes Larratt)
Subject: Partition tables have serial #'s in DOS 4.0 and 5.0?

I'm writing a primitive scanner for our local labs which will compare the
bootstrap code in the partition table record to a know-good copy, but have
run into a problem: in DOS 3.3-created partition tables, the code just ends,
while apparently 4.0 and 5.0 create what I assume is a serial number in the
four bytes following the code?  (I assume it's a serial number because the
upper 16 bits, in each case I've examined, match the upper 16 bits of the
serial number assigned to the primary partition).

Can anyone point me to a reference which will confirm/explain this, and/or
a good source of info on DOS' method of hashing unique serial numbers?

Thanks in advance,

- --
===/| Glenn Forbes Larratt      |    CRC OCIS     | "So, what do we need?" |/
==/| [e-mail] (Internet) | Rice University | "To get laid!"        |/=
=/| GLRATT@RICEVM2 (Bitnet)     |=================| "Can we get that     |/==
/| The Lab Ratt (not briggs :-) |  Neil  Talian?  |       at the 7-11?" |/===

------------------------------

Date:    Tue, 30 Jul 91 09:50:40 -0700
>From:    [e-mail] (Rob Slade)
Subject: Computer operations and viral operations



FUNGEN1.CVP   910727

           Computer operations and viral operations

Having defined what viral programs are, let's look at what
computers are, and do, briefly.  The functions that we ask of
computers tend to fall into a few general categories.

Computers are great at copying.  This makes them useful for
storing and communicating data, and for much of the "information
processing" that we ask them to do, such as word processing.
Computers are also great for the automation of repetitive tasks.
Programming allows computers to perform the same tasks, in the
same way, with only one initiating call.  Indeed, we can, on
occasion, eliminate the need for the call, as programs can be
designed to make "decisions" on the basis of data available.
Finally, computer processors need not be specially built for
each task assigned to them: computers are multi-purpose tools
which can do as many jobs as the programs available to them.

All computer operations and programs are comprised of these
three components: copying, automatic operation, "decision"
making: and, in various combinations, can fulfill many
functions.  It is no coincidence that it is these same functions
which allow computer viral programs to operate.

The first function of a viral program is to reproduce.  In other
words, to copy.  This copying operation must be automatic, since
the operator is not an actively informed party to the function.
In most cases, viral program must come to some decision aobut
when and whether to infect a program or disk, or when to deliver
a "payload".  All of these operations must be performed
regardless of the purpose for which the specific computer is
intended.

It should thus be clear that computer viral programs use the
most basic of computer functions and operations.  It should also
be clear that no additional functions are necessary for the
operation of viral programs.  Taking these two facts together,
noone should be surprised at the conclusion reached a number of
years ago that not only is it extremely difficult to
differentiate computer viral programs from valid programs, but
that there can be no single identifying feature that can be used
for such distinction.  Without running the program, or
simulating its operation, there is no way to say that this
program is viral and that one is valid.

The fact that computer viral operations are, in fact, the most
basic of computer operations means that it is very difficult to
defend against intrusion by viral programs.  In terms of
"guaranteed protection" we are left with Jeff Richards' Laws of
Data Security:
         1)   Don't buy a computer.
         2)   If you do buy a computer, don't turn it on.

copyright Robert M. Slade, 1991   FUNGEN1.CVP   910729


=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Wed, 31 Jul 91 11:37:00 -0400
>From:    "Dr. Harold Joseph Highland, FICS" <[e-mail]>
Subject: Call for Papers - IFIP/SEC '92

                     C A L L        F O R      P A P E R S

       THE IFIP/SEC'92 INTERNATIONAL CONFERENCE on COMPUTER SECURITY

                         May 27-29, 1992    Singapore


The purpose of the 1992 International Federation for Information
Processing Security Conference [IFIP/Sec'92] is to provide a forum for
the interchange of ideas, research results, and development activities
and applications among academicians and practitioners in information,
computer and systems sciences.  IFIP/Sec'92 will consist of advance
seminars, tutorials, open forums, distinguished keynote speakers, and
the presentation of high-quality accepted papers.  A high degree of
interaction and discussion among Conference participants is expected,
as a workshop-like setting is promoted.

IFIP/Sec'92 is co-sponsored by The International Federation for
Information Processing, Technical Committee 11 on Security and
Protection in Information Processing Systems [IFIP/TC11] and The EDP
Auditor's Association.  IFIP/Sec'92 is organized by the Singapore
Computer Society and IFIP/TC11 and is sponsored by the National
Computer Board, Singapore, Singapore Federation of Computer Industry,
Microcomputer Trade Association of Singapore and the EDP Auditors
Association of Singapore

Because IFIP/Sec'92 is a non-profit activity funded primarily by
registration fees, all participants and speakers are expected to have
their organizations bear the costs of their expenses and registration.
Presenters of papers will pay a reduced conference fee.


WHO SHOULD ATTEND

The conference is intended for computer security researchers,
managers, advisors, EDP auditors from government and industry, as well
as other information technology professionals interested in computer
security.


CONFERENCE THEME

The Eighth in a series of conferences devoted to advances in data,
computer and communication security management, planning and control,
this Conference will encompass developments in both theory and
practice.  Papers are invited in the areas shown and may be
theoretical, conceptual, tutorial or descriptive in nature. Submitted
papers will be refereed, and those presented at the Conference will be
included in the proceedings.  Submissions must not have been
previously published and must be the original work of the author(s).

The theme for IFIP/Sec'92 is "Computer Security and Control: From Small
Systems to Large."  Possible topics of submissions include, but are not
restricted to:

o    Auditing the Small Systems Environment
o    Auditing Workstations
o    PC and Microcomputer Security
o    Security and Control of LANs and WANs
o    OSI Security and Management
o    GOSIP - Government OSI Protocol
o    Electronic Data Interchange Security
o    Management and Control of Cryptographic Systems
o    Security in High Performance Transaction Systems
o    Data Security in Developing Countries
o    Software Property Rights
o    Trans-border Data Flows
o    ITSEC (IT Security Evaluation Criteria - The Whitebook)
o    Database Security
o    Risk Assessment and Management
o    Legal Responses to Computer Crime/Privacy
o    Smart Cards for Information Systems Security
o    Biometric Systems for Access Control


THE REFEREEING PROCESS

All papers and panel proposals received by the submission deadline
will be considered for presentation at the Conference.  To ensure
acceptance of high-quality papers, each paper submitted will be blind
refereed.

All papers presented at IFIP/Sec'92 will be included in the Conference
proceedings, copies of which will be provided to Conference attendees.
All papers presented, will also be included in proceedings to be
published by Elsevier Science Publishers B.V. [North-Holland].


INSTRUCTIONS TO AUTHORS

[1]  Three (3) copies of the full paper, consisting of 22-26
     double-spaced (approximately 5000 words), typewritten pages,
     including diagrams, must be received no later than 1 December 1991.
     Diskettes and electronically transmitted papers will not be
     accepted.      Papers must be sent to the Program chairman.

[2]  Each paper must have a title page which includes the title of the
     paper, full name of all authors, and their complete addresses
     including affiliation(s), telephone number(s) and e-mail
     address(es).  To facilitate the blind review process, these
     particulars should appear only on a separate title page.

[3]  The language of the Conference is English.

[4]  The first page of the manuscript should include the title and a
     300 word abstract of the paper.


IMPORTANT DATES

o    Full papers to be received by the Program Committee by 1 December 1991.

o    Notification of accepted papers will be mailed to the author on or
     before 1 March 1992.

o    Accepted manuscripts, in camera-ready form, are due no later than 15
     April 1992.

o    Conference: 27-29 May 1992.


WHOM TO CONTACT

Questions or matters relating to the Conference Program should be directed
to the Program chair:

Mr. Guy G. Gable
Department of Information Systems and Computer Science
National University of Singapore
Singapore 0511
Telephone: [phone]   Fax: [phone]  E-mail: ISCGUYGG@NUSVM

For information on any aspect of the Conference other than Program,
panel, or paper submissions, contact the Conference Chair:

Mr. Wee Tew Lim
Organising Chairman
c/o Singapore Computer Society
71 Science Park Drive
The NCB Building
Singapore 0511
Telephone: [phone]    Fax: [phone]

Papers should be sent to:

The Secretariat
IFIP/Sec '92
c/o Singapore Computer Society
71 Science Park Drive
The NCB Building
Singapore 0511


In the States and Canada, inquiries about the Conference can be sent to:

Dr. Harold Joseph Highland, FICS
Chairman, IFIP/WG11.8 - Information Security Education and Training
562 Croydon Road  Elmont, New York 11003-2814  USA
Telephone: [phone]                 Telex: 650 406 5012 [MCIUW]
Electronic mail:     [e-mail]
 X.400: C=US/A=MCI/S=Highland/D=ID=4065012         MCI Mail: 406 5012

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 134]
******************************************
VIRUS-L Digest   Friday,  2 Aug 1991    Volume 4 : Issue 135

Today's Topics:

ME
re: High memory (PC)
Scanning DOS files under UNIX ? (PC) (UNIX)
Re: Self-scanning executables (PC)
Re: Virus Scan V57 and V77. (PC)
Info re viruses in shrinkwrap software?
Re: Self-scanning executables (PC)
Re: Brunnstein (CARO) virus catalog files
Need help fighting FORM (PC)
Re: Self-scanning executables (PC)
request information (PC)
OS/2 Viruses (PC) (OS/2)
Rip-off software package (PC)
Proposal for standard virus signatures notation

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Wed, 31 Jul 91 18:25:02 +0100
>From:    [e-mail]
Subject: ME

I was somewhat taken back with Ross Greenberg's abraisive response
(issue 125) to my posting (issue 119) about the anti-virus product
review in the UK magazine PC Plus.  Without plumbing the depths of
personal abuse I would like to defend myself and respond to a couple
of the 'criticisms' made.

>}Declaration of interests: I work at Thecia System Ltd, we produce an
>}anti-virus product called Virus Clean, which was not invited for inclusion
>}in Hamilton's review.
>
>The crux of the problem, certainly.  Did you, by any chance, have the
>opportunity to forward a copy of your code to VB for inclusion in
>their review(s), or did you expect them to track you down?

I think that you are barking up the wrong tree with this time Ross:
    This caveat was intended to show that I had no particular axe to grind
    (eg regarding unfair treatment of our product) in my comments, and that
    I practice what I preach in terms of disclosing my interests.

    My discussion was of the review in PC Plus, not of the similar review
    recently in the Virus Bulletiin.  However if you are interested; Edward
    is certainly aware of our product but he did not request a copy for
    review.  In fact the subject has never come up in our occasional
    conversations.

>}I am not suggesting that Mark Hamilton has deliberately misrepresented
>}the products of these companies, but that these relationships should be
>}kept in mind when reading the review.
>
>Ah, but what you write *does* suggest that you have a problem with
>either Hamilton's credibility or VB's or both.

My intention was to raise awareness of magazine readers of the possible
partiality of magazine reviews.  Having seen all issues of VB, and even
having contributed (at a time when I had no other commercial interest in
the subject), I have had 2 years to form an opinion.  However I shall
not force this on anyone, but rather respect that other people's range
from Ross's unstinting praise (well almost) to outright incredulity.

I was present at one event that Hamilton subsequently reported on, and
my recollection differed from his report in only one area; the behaviour
of Hamilton himself and the subsequent response.  This only underlines
the lesson I learnt from seeing events and names mangled in local
newspapers, seek corroboration of any news item that may affect you.

Perhaps my previous posting would have been fairer if I had included
comments about Future Publishing, the publishers of PC PLUS. Suffice
to say that their computer titles range from the very good Amiga Shopper
down to their roguish Computer Express.

My thanks especially to those who responded directly to my previous posting,
if you haven't got a reply yet I promise that I shall send it when I next
login.

Many thanks for your time & attention,
ANTHONY NAGGS

Systems Designer                        #
Electronics Engineer                    #
Program Implementor                     #   Silly question #1:
Software Tester                         #   Who lit the fuse for the big bang?
Occasional book & magazine contributor  #
& PC Virus Analyser since 1988          #

------------------------------

Date:    Wed, 31 Jul 91 18:13:00 -0500
>From:    Rich <[e-mail]>
Subject: re: High memory (PC)

>From:    "William Walker C60223 x4570" <[e-mail]>

>From:    [e-mail] (A. Padgett Peterson)
>
>There is a portion of extended memory on a '286 or '386, which
>Microsoft calls the High Memory Area (HMA), which is accessible from
>real mode.  A good explanation of how it works is given in the article
>"Power Programming" by Ray Duncan, in the June 27, 1989 issue of PC
>Magazine, part of which I've quoted below:
>
>> "Recall the method by which physical addresses are generated in real
>> mode.  The contents of a segment register are shifted left 4 bits
>> and added to a 16-bit offset.  On an 8086/88 machine, if the result
>> overflows the 20-bit addresses supported by the CPU, the address
>> simply wraps--that is, the upper bits are discarded.  80286- and
>> 80386-based PCs can support larger physical addresses (24 bits and
>> 32 bits, respectively), but this capability is ordinarily not
>> apparent when DOS is running.  That's because these machines have
>> special hardware to disable the most-significant address lines in
>> real mode, making the machine behave more like an 8088.
>
>> "Consider what happens, however, on an 80286 when you enable the A20
>> line and place the value FFFFh in one of the segment registers.
>> Enabling the A20 line allows the generation of 21-bit physical
>> addresses.  And when FFFFh is shifted left 4 bits and added to a
>> 16-bit offset, the result will fall in the address range FFFF0h-
>> 10FFEFh.  In other words, enabling the A20 line allows the first
>> 65,520 bytes of extended memory to be addressed WITHOUT LEAVING REAL
>> MODE."  [my emphasis - WWW]
>
>> - Duncan, Ray.  Power programming.  PC Magazine, V8 I12 (June 27,
>>   1989), p. 321.  Copyright Ziff-Davis Publishing Co. 1989
>
>Knowing this, suppose a virus has somehow infected a machine with a
>pre-DOS validator, relocating it as though it was a normal boot sector
>or MBR.  Also suppose that it has enabled the A20 line and stored part
>or all of itself in the HMA, with vectors pointing up there.  These
>vectors would by necessity have a segment prefix greater than 0F000h.
>Now, when the validator gets control, it would mistakenly believe that
>those vectors pointed into ROM below the 1M line if it only examined
>the segment prefix.  But if it calculated the full absolute addresses,
>it would easily see that the vectors pointed into the HMA, not ROM.
>
>Such a virus, though possible, would not be very viable, since running
>HIMEM.SYS or anything which used memory in protected mode would wipe
>out the virus code in the HMA.  And, if the virus somehow protected
>itself, these programs would bomb out, giving the user a clue that
>something was wrong.

I recently saw a program (and the .ASM source) which goes TSR and
waits for the user to execute LOGIN (.com, .exe, or .bat).  It then
records everything in a hidden file named TESTING<alt-255>.TMP.  It
was written at George Washington High School and left on the super-
visor's machines on a Novell Network.  Now, taking this into account,
couldn't a virus be written which would place itself in that memory
you were talking about, and remain undetectable to the methods you
were describing above?  It could scan for HIMEM.SYS, QEMM, etc, and
if it finds one being executed, move itself to conventional memory
(where it COULD be detected, but won't, since you've already scanned
it with the pre-D thing) and then load the memory driver?

One other point:  I got to thinking earlier today (uh oh!).... Since
you can re-write the BIOS table to intercept interrupts (e.g. int 09h
is intercepted by SideKick, to check for the ctrl-alt key combo),
this indicates that the BIOS vector is in RAM.  This is copied from
ROM on bootup, right?  Can't you write a driver (.sys) file to be
executed in config.sys which would go TSR and then warn you everytime
a program re-directed an interrupt?  I mean, you should know SideKick
is doing it, but if something that SHOULDN'T be doing it does it,
it might be a good sign that something's up!  (the novel password
stealer intercepted the dos interrupt, 021h, which is itself
intercepted on boot by the novel software.  so the hacker re-hooked
it AFTER novel did, so that when a DOS function is called, it goes
through the password stealer, then through Novell, then through the
regular interrupt handler...)  Anyway, I've never written a .SYS
file, nor have I seen any information on how to do it.  Can someone
point me in the right direction so that I can learn how to write one?
If no one else likes my idea, *I* at least would like it on MY
system....

- ----------------------+
Richard Holland       |
                      |
[e-mail]  |
[e-mail] |
[e-mail]     |
- ----------------------+

------------------------------

Date:    Wed, 31 Jul 91 17:53:52 +0000
>From:    [e-mail] (Aidan Saunders)
Subject: Scanning DOS files under UNIX ? (PC) (UNIX)

Are there UNIX scanners around that check DOS files ?

I have a bunch of PC's that use a Sun as a file server holding both
applications & users files.  (Well, that's what we're about to set
up!)  I would like to run a scanner on the Sun to scan these DOS
files.  That way, I can easily automate regular scanning and avoid the
problems caused by stealth (& other) viruses that are active in memory
when scanning.

Have any of you scanner writers tried this ?  - or have I missed
something ?

I would guess a Unix version of an existing Dos scanner is not too
difficult.

Any comments?

Aidan
- --
- ----------------------------------------------
ARPA :: [e-mail]
UUCP :: ...!ukc!newcastle.ac.uk!a.c.g.saunders
- ----------------------------------------------

------------------------------

Date:    31 Jul 91 18:57:32 -0400
>From:    Kevin Dean <[e-mail]>
Subject: Re: Self-scanning executables (PC)

In digest #132, [e-mail] (Fridrik Skulason) writes:

> Well, this is of just as much use as a simple checksumming algorithm-
> it is very unlikely that a virus will attempt to atteck the
> encryption algorithm itself - trying to "fake" the CRC.  A much more
> effective method is to use "stealth" techniques.

> If the implementation of this algorithm detects infection by Frodo
> (4096), it is worth considering...

He is quite right.  Stealth viruses intercept the DOS interrupt and
check for file open of the infected executable (which my code has to do
in order to run the self-check) and disinfect the executable before
passing the file open command on to DOS.  My algorithm won't detect
that since it will be running on a (now) clean copy of the executable.

I have some ideas on how to detect stealth viruses.  I'll test them out
as soon as I can and post the results here.

In digest #133, [e-mail] (John Francis) writes:

> Unfortunately this is nothing more than "Ignorance Protection".
> There has to be some way of calculating the initial CRC when the
> program is built - they don't appear in the executable by magic!
> This must be by some method that is faster than exhaustive search,
> or else nobody will use CRC protection. The same algorithms are
> available to virus writers.

An external program is run on the executable to generate the initial
CRC.  This program searches for a predefined string in the executable
and _replaces_ it with the CRC information.  Once the string has been
replaced, there is no way to find it again, hence the need for an
exhaustive search.  T'ain't easy.

------------------------------

Date:    01 Aug 91 06:59:01 +0000
>From:    [e-mail] (Doug McLaren, esquire.)
Subject: Re: Virus Scan V57 and V77. (PC)

motcid![e-mail] (Bill Dyer) writes:
>[e-mail] (Andrew Brennan) writes:
>
>While I am here, a question about Stoned.  From what I can tell,
>Stoned is a memory resident program that resides in the partition
>table on hard disks and the boot sector on floppies.  My question is
>what triggers the thing to infect a floppy from the hard disk?  In
>other words, what interupt is it stealing?  Second question, can
>Stoned infect other places besides the partition table?  We have a PC
>board plugged into one of our suns here at work, and I think the thing
>is infected with Stoned.  However, the thing does not have a standard
Yes, and another question about Stoned.

I got it once, a while back.  I used Clean and got rid of it, and it
never came back.

But how did I get it?  I had been ftp'ing at the time, and had not
actually exchanged any disks recently.  I then ran all the programs I
ftp'd through Checkout which Scans and re-Archives w/ Lha.  But
Checkout crashed halfway through the set saying my disk was infected
(I never did see the message saying w/ what ...)  I ran Scan and it
said Stoned virus found somewhere on my HD.  But if Stoned infects
disks only, how did I get it.  And how did it crop up from
de-archiving it?  (Or did it?)  I thought only the Dark Avenger did
that?  Any ideas ?

- --
| Doug McLaren              | "Good tea ...        |
| [e-mail] |  nice house." - Worf |
- ----------------------------------------------------

------------------------------

Date:    Thu, 01 Aug 91 13:06:31 +0000
>From:    [e-mail] (Greg Broiles)
Subject: Info re viruses in shrinkwrap software?

The latest issue of Byte has a cover story on viruses and security software -
a rather disappointing article, truth be told.  They do some rudimentary
testing of a few antivirals and come up with a simplistic little
reccommendations-box.  Blech. :(

Anyway, in the middle of the aforementioned yukky article, there's one of
those sidebars along the lines of "How not to get viruses", which included
tips like "only use shrinkwrapped software" and "only download software
from trusted sources like BIX" (BIX is Byte's own online service).

I'm planning to write a grouchy letter to the editors re their *wrong*
ideas about virus propagation, and am looking for specific examples of
commercial software that's been infected at the factory or duplication site.
I've read of quite a few examples of this over the years in comp.virus
but never bothered to collect them into a useful list; but I'm in the
mood to now.

So.. if you know of an instance of software being infected before delivery
to customers (leaving aside, for the moment, the issue of stores which re-wrap
software after demos or customer returns), please post it, or mail to me.
I'll summarize to the net once replies die down.

- --
".. organized crime is the price we pay for organization." - Raymond Chandler
Greg Broiles          | CI$:      74017,3623   |          [e-mail]
PO Box 8988, Portland, OR  97207-8988          |            MCIMail: gbroiles

------------------------------

Date:    Thu, 01 Aug 91 09:11:00 -0400
>From:    Jeff Boyd <[e-mail]>
Subject: Re: Self-scanning executables (PC)

John Francis <[e-mail]> wrote:
>  Somewhere on CompuServe, Kevin Dean writes:
>>  Cracking the algorithm is not a trivial task: a virus has one chance
>>  in four billion (2^32) of successfully infecting a program or, if it
>>  decides to fool the algorithm by changing the stored CRC, would lock
>>  up a 386 for hours bordering on days to find and change it.
>
>  Unfortunately this is nothing more than "Ignorance Protection".  There
>  has to be some way of calculating the initial CRC when the program is
>  built - they don't appear in the executable by magic!

Correct.

>  This must be by some method that is faster than exhaustive search, or
>  else nobody will use CRC protection.

Correct again.

>  The same algorithms are available to virus writers.

Wrong.

>  It won't take long to find the encryption code in an executable ...

Wrong.

The insertion of the CRC into the program is a 1-way ticket. Only
exhaustive search can pull it out. Can a virus use the same insertion
technique to plant itself without changing the present CRC (which is
stored in the program) *AND* without changing the file size?

You tell me how easy that would be.

------------------------------

Date:    Thu, 01 Aug 91 10:14:12 -0400
>From:    Kenneth R. van Wyk <[e-mail]>
Subject: Re: Brunnstein (CARO) virus catalog files

For all you VIRUS-L/comp.virus readers in the Australia region, the
CARO virus catalog files are now also available by anonymous FTP on
suna.mqcc.mq.oz.au [IP number 137.111.161.1] in the directory,
pub/Virus/Brunnstein.

Ken van Wyk

------------------------------

Date:    01 Aug 91 17:37:11 +0000
>From:    Tom Killalea <[e-mail]>
Subject: Need help fighting FORM (PC)

FORM is currently causing our PC users major headaches.  McAfee Clean
doesn't always clean it (I'm using 7.6v80).  Doing SYS to make a
system disk thus overwriting the boot sector works but is a bit of a
kludge.  Any ideas ?

Many thanks,

Tom Killalea
Systems Programmer

- --
Tom Killalea |     011 353 1 702 2165    |  Trinity College
             |   [e-mail]   |

------------------------------

Date:    Thu, 01 Aug 91 16:46:00 -0400
>From:    Jeff Boyd <[e-mail]>
Subject: Re: Self-scanning executables (PC)

Padgett Peterson <[e-mail]> wrote:
>  Unfortunately, a "stealth" virus will defeat this method ... the
>  routine only "sees" the program as it was, not as it is, the routine
>  passes.

The virus must intercept the calls to read the disk image, notice that
the file is already infected, and replace the interrupt return values
with "good-looking" data. Will 4096 really do this? If it can, I don't
understand how anyone has ever discovered it.

------------------------------

Date:    Thu, 01 Aug 91 20:12:00 -0600
>From:    CESAR <[e-mail]>
Subject: request information (PC)

Hi, I'm write from ITESO University, in last days I wrote to
[e-mail], for solicit information abot how we can have the
last versions of SCAN, CLEAN, etc. Which is the cost of license?.

But Mcafee do not answer me, How we can do it?

Thanks in Advance.

I.E. Cesar E. H. White
Public Relations Manager
ITESO University

BITNET:   Cesar@iteso
INTERNET: [e-mail]

------------------------------

Date:    Fri, 02 Aug 91 18:25:00 +1000
>From:    "William J. Caelli" <[e-mail]>
Subject: OS/2 Viruses (PC) (OS/2)

There have been a number of questions about whether or not there have
been any reports of OS/2 viruses - particularly program ( as distinct
from boot-sector ) viruses. Has anyone got any reports of such OS/2
viruses.

Bill Caelli - QUT Australia.

------------------------------

Date:    Fri, 02 Aug 91 12:07:41 +0700
>From:    "Jan R. Terpstra" <[e-mail]>
Subject: Rip-off software package (PC)

Recently it was brought to my attention that a so called ShareWare
package of anti-virus utitlities is offered by Mauro Bollini of Italy
at US $45.  After checking a recent copy of the anti-virus package, it
turns out that it consists of bootlegged copies of several program's
from Frisk, Alan Solomon, McAfee and my own virscan.dat file.

For those of you wanting to persue this matter, I can scoop up a copy
of the complete package as offered by Mauro Bollini. Who, by the way,
also operates a virus exchange BBS in Italy.

<JT>

Jan R. Terpstra (moderator of the FIDONET VIRUS conference in my spare time)

Usual disclaimers apply.

------------------------------

Date:    Fri, 02 Aug 91 13:07:50 +0700
>From:    "Jan R. Terpstra" <[e-mail]>
Subject: Proposal for standard virus signatures notation

After lengthy discussions with a number of people, three independant
authors of virus scanning products and myself (as the keeper of the
VIRSCAN.DAT virus signature file) have agreed upon a standard notation
for virus signatures.  As far as I know at this time, CARO will adopt
this method too. (Klaus?)

The method is non-proprietary and hereby donated to the public domain.

Your comments and suggestions are welcome.

                        -0-0-0-0-0-0-0-0-0-0-0-0-

A virus signature is a hexadecimal pattern of part of the active code
of the virus, prefarably a unique part to allow positive
identification of a virus.  The hexadecimal string must be at least 12
bytes long, with a maximum of 40 bytes. Long signatures are
recommended to decrease the change of flase psotives. The string
should be carefully extracted and preferably not contain often used
sequences of instructions like operating system calls.

A virus signature is represented as a so called "Two-Byte-Hex" string,
i.e.  each byte is represented in two ASCII characters in the range
0....9 and/or A....F.
  Example: 3E550BDF3D550D45863211FA

For easier reading, spaces between the bytes are allowed.
  Example: 3E 55 0B DF 3D 55 0D 45 86 32 11 FA
       or: 3E55 0BDF 3D55 0D45 8632 11FA

In a virus signature, wildcards characters may be used to recognize so
called selfmodifying virus code.  Below is a description of the
wildcard notation:

??  = Always skip this byte when scanning (don't care).
      Signature "1122??445566" should trigger on a the pattern with any value
      in the third byte of the signature.  "1122CC445566" and "1122FA445566"
      triggers, but "1122445566" does not
      Multiple ?? are allowed, but to skip more than one byte, usage of the
      "*X" notation is recommended.

?n  = Always disregard the high nibble of this byte when scanning, but DO test
      the low nibble.
      Signature "1122?34455" triggers for any value in the high nibble of the
      third byte, i.e. "1122A34455" triggers, but "1122AA4455" does not.

n?  = Always disregard the low nibble of this byte when scanning, but DO
      test the high nibble.
      Signature "11223?445566" triggers for any value in the low nibble of the
      third byte, i.e. "11223A4455" triggers, but "1122AA4455" does not.

*x  = Skip exactly X bytes (X = 1 to F), i.e. the contents of precisely X
      bytes are to be disregarded.
      Signature "1122*3445566" triggers on "1122AABBCC445566", but not on
      but not on "1122AABBCCDD445566" or "1122AA445566".
      Note: X1 equals to ??.

%x  = Skip 0 to a specified number of bytes. (X = 1 to F), i.e. the contents
      of zero up to X bytes are to be disregarded.
      Signature "1122%3445566" triggers on "1122445566" and "1122AABB445566"
      but not on "1122AABBCCDD4455".

Note: The first TWO bytes of a virus signasture can not contain wildcards.
      This allows simplified word hashing tables to be implemented in virus
      scanners that use the proposed string format as input.
      To minimize the chance of false positives, it is preferred that the
      *X and %X notation not be used in the last byte of a virus signature,
      though this might be unavoidable for some self-garbling viruses.


Some examples:

 55 AA 33 ?? 90 01 FF = Match 55AA33, disregard 1 byte and match 9001FF.

 55 AA 33 ?4 90 01 FF = Match 55AA33, disregard the high nibble of the 4th
                        byte, match "4" in the low nibble and match the 9001FF
                        pattern.

 55 AA 33 4? 90 01 FF = Match 55AA33, disregard the low nibble of the 4th
                        byte, match "4" in the high nibble and match the
                        9001FF pattern.

 55 AA 33 *7 90 01 FF = Match 55AA33, and match 9001FF if found after exactly
                        7 bytes from the end of the 55AA33 pattern.

 55 AA 33 %A 90 01 FF = Match 55AA33 and match 9001FF if found within 10 bytes
                        from the end of the 55AA33 pattern.

                        -0-0-0-0-0-0-0-0-0-0-0-0-
Try this one for yourself:  55 AA %3 EF *4 BE ?? B? ?4 FE  :-)

Jan R. Terpstra (keeper of VIRSCAN.DAT in my spare time)

Usual disclaimer applies.

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 135]
******************************************
VIRUS-L Digest   Monday,  5 Aug 1991    Volume 4 : Issue 136

Today's Topics:

Re: viruses in the press
Self-scanning executables (PC)
Re: Philosophy, comments & Re: long and technical (PC)
Is Dark Avenger Really here? (PC)
Re: Self-scanning executables (PC)
Floppy Door Close TSR? (PC)
Re: Philosophy, comments & Re: longer and technicaller
Re: Virus for Sale
Re: request information (PC)
Scan and Clean problems (PC)
Re: Rip-off software package (PC)
re: High memory (PC), "Stealth" (PC), Review the Literature
re: Can such a virus be written... (PC) (Amiga)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    02 Aug 91 13:18:18 +0000
>From:    ehviea!sun4dts.dts.ine.philips.nl![e-mail] (derek)
Subject: Re: viruses in the press

[e-mail] (Paul Coen) writes:

>Well, all I can say is that in a document that I wrote for the Drew
>University Academic Computer Center (and I think that the department
>that hands out freshman computers included it in their fresman
>handbook) started out by saying that you should forget what you've
>heard about viruses from the press, since too much of it is
>inaccurate.

[Lots of stuff deleted]

>Paul Coen -- [e-mail], [e-mail], [e-mail]
>Disclaimer: These ARE my opinions -- I've been taking the summer off.

I NEVER buy newspapers - they are not worth the trees felled to produce
them.

2. I take TV news with a pinch of salt - they only show things that have
   interesting pictures with them - most of the other stuff they ignore.

3. Radio news is useful for the political headlines. Especially when you
   understand several languages, and get the news from different sources.

4. Even technical papers can be wrong - but if they wrote in English,
   instead of some academicese (or whatever) we might even be able to
   spot that! :-)

Greetings from the Ancient Duchy of Brabant.

Best Regards, Derek Carr
[e-mail]           Philips IE TQV-5 Eindhoven, The Netherlands
Standard Disclaimers apply.


------------------------------

Date:    Fri, 02 Aug 91 10:18:31 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: Self-scanning executables (PC)

>From:    [e-mail]

>  If I disassembled/debuged some of the CRC checkers, _I_
>probably could write a virus which checked for (some variants) of
>those checkers and modified its infections accordingly; if I didn't
>have source for the CRC generator, I might find it a difficult
>mathematical problem to solve for the values to place in memory.

The "stealth" viruses do not bother changing the CRC, when resident, they
just always return the correct program so that it matches the CRC wherever
it is stored & however it is calculated.

This brings to light the inherant problem with self-checking CRC (even those
that use DES or better) programs, they are self checking.

Understanding this requires consideration of the order in which an infected
program with a "self-checker" and infected by a "stealth" virus will execute.

1) User requests program to be run
2) CLI (typically COMMAND.COM) loads program into memory & transfers execution
3) The virus, takes control on load since it has subverted the initial code
   (may be only 3-5 bytes).
4) The virus goes resident in memory, removes itself from low memory, and
   restores original program.
5) Virus code transfers control to original program
6) Self checker executes - if it checks self in memory, it finds original
   code - if checks self on disk, virus intercepts call & strips virus off
   code first, presenting original code.
7) Self check passes test

Now consider the case where the checksum routine is resident in memory.

1) User requests program to be run
2) CLI (typically COMMAND.COM) loads program into memory & transfers execution
3) Resident checker intercepts execution transfer and performs checksum on
   code loaded into memory
4) Virus is detected before going resident and execution is disallowed.

Since the virus is detected before execution, "stealth" will not help it.

Now there are some caveats to the above scenario to prevent "end-runs" by
virus code, primarily in that the checker becomes resident no later than as
part of CONFIG.SYS (better if from BIOS, but as first line in CONFIG.SYS
is probably Good Enough. Risk increases dramatically if residence is from
AUTOEXEC.BAT or later since viruses have been known to go straight for
COMMAND.COM & if integrity management code is added later, "stealth" will
have a means to go resident before the anti-virus program loads.

Currently, there seem to be three schools of thought about where the checksum
should be stored. McAfee Associates /AV switch adds about ten bytes to the end
of an executable program. Norton Anti-Virus adds a 77 byte file to the
directory containing the executable file. Enigma-Logic's Virus-Safe creates
a special file in its directory that contains all checksum values.

My personal preference is for the Enigma-Logic methodology since it does not
rely on anything in the file being opened or the current directory. Self
checking files may fail on any addition and extra clusters can add up fast.
(These are the three products I am most familiar with - obviously there
are others).

However, ANY integrity checking is several orders of magnitude better than
none.

                    Padgett

------------------------------

Date:    Fri, 02 Aug 91 07:48:06 -0700
>From:    [e-mail]
Subject: Re: Philosophy, comments & Re: long and technical (PC)

In a recent VIRUS-L posting [e-mail] (Wm E
Davidsen Jr) asks:

 >   Which braindead machines do that? I know about BIOS shadowing,
 > but I don't think I've ever found one which didn't set write
 > protect so memory maps would think it was ROM.

It is not only the hardware which is providing ROM shadowing,
but also Expanded Memory Manager programs such as QEMM and
386max. While I sincerely hope that all such programs will set
the memory type to read-only in the segment descriptor
attributes, I have not done an exhaustive verification of this
function.

In reviews of memory managers it would be good for the
reviewers to use a verification of protection of shadowed ROM
as a pass/fail test for the packages.

Fritz Schneider ([e-mail])

------------------------------

Date:    Fri, 02 Aug 91 09:38:00 -0500
>From:    [e-mail]
Subject: Is Dark Avenger Really here? (PC)

Well, I have a bit of a weird one that I _suspect_ may be a false
trip...

McAfee VIRUSCAN Version 7.6V80 _sometimes_ indicates that it has found
Dark Avenger in memory.  Doing a "DIR /W" seems to reliably clear that
message from SCAN.  From what I under- stand about Dark Avenger this
should not happen.  *I think* that once Dark Avenger goes resident, it
stays.

Given the fact that we have had a MAJOR infection of Dark Avenger on
campus, we're all paranoid...

Scanning the disks with the /a option (scan every file) finds nothing.

Can y'all offer any suggestions?  I need to clear this one up.

Oz (Rich Osman)                    INTERNET: [e-mail]
[phone] (w)
[phone] (h, merciless machine)
[phone] (just the fax)

------------------------------

Date:    02 Aug 91 15:41:58 +0000
>From:    [e-mail] (Fridrik Skulason)
Subject: Re: Self-scanning executables (PC)

I wrote:
>  Well, this is of just as much use as a simple checksumming algorithm -

Jeff Boyd wrote:
>You either overlook or underestimate the value of it.

No, I was commenting on the fact that the quality of the algorithm is
not the important issue - simple checksumming or a complicated one-way
hash function, it really does not matter - if the implementation does
not catch stealth viruses it is not perfect.  Granted, it may detect
the infection of any non-stealth virus, but unless it is (for example)
able to catch Frodo, the actual algorithm used does not matter to me.

- -frisk

------------------------------

Date:    02 Aug 91 18:36:03 +0000
>From:    [e-mail] (Jesse Chisholm AAC-RjesseD)
Subject: Floppy Door Close TSR? (PC)

Folks:
    Is there a TSR program available that scans a floppy whenever
the floppy door closes?  Is it even possible to write one?  Are any of
you all working on one (McAfee, Padgett, ...)?

Jesse Chisholm          | Disclaimer: My opinions are rarely understood, let
[e-mail] | tel: [phone] | alone held, by this company.
[e-mail]   | fax: [phone] |-----------------------------
======== This company has officially disavowed all knowledge of my opinions.
- --
| "Ma gavte la nata." translation: "Be so kind as to remove the cork."
|  -- obscure Italian insult, observing that one is so full of themselves
|     that the cause must be a cork placed in the anal orifice.

------------------------------

Date:    01 Aug 91 13:15:57 +0000
>From:    [e-mail] (Wm E Davidsen Jr)
Subject: Re: Philosophy, comments & Re: longer and technicaller

[e-mail] (Mark Aitchison, U of Canty; Physics) writes:

| (5) I've run a checking program on a Sparc emulation of an AT, and noticed the
| difference (I didn't even write the program with that system in mind) - any
| virtual machine running under a 386 would be even easier to detect, given the
| speed considerations - i.e. a 386 cannot emulate a 386 of the same clock speed
| without making the extra time in hardware traps, etc obvious).

  Virtual 386 is a hardware mode. I assure you that if it slowed the
machine notably millions of people would not use the products which
employ it, such as QEMM, 386MAX, and EMM386.
- --
bill davidsen    ([e-mail] -or- uunet!crdgw1!crdos1!davidsen)
  GE Corp R&D Center, Information Systems Operation, tech support group
  Moderator comp.binaries.ibm.pc and 386-users digest.

------------------------------

Date:    Fri, 02 Aug 91 15:03:46 +0000
>From:    motcid!sapphire![e-mail] (James P. Dusek)
Subject: Re: Virus for Sale

    Thats it, we could con a newsnetwork into printing an artical
on how the author of a virus successfully sued the author of a virus
checker because the checker used part of the virus's code to do the
checking. Than we could nail these maggots as they try to sue! What
ever happened to the SCA, did they get busted or something?

                            J.Dusek

------------------------------

Date:    Sat, 03 Aug 91 03:30:25 +0000
>From:    [e-mail] (McAfee Associates)
Subject: Re: request information (PC)

[e-mail] (CESAR) writes:
>Hi, I'm write from ITESO University, in last days I wrote to
>[e-mail], for solicit information abot how we can have the
>last versions of SCAN, CLEAN, etc. Which is the cost of license?.
>
>But Mcafee do not answer me, How we can do it?

Hello Mr. White,

Attempts to contact you by the InterNet have resulted in the mail
being bounced back by the mailer-daemon.  If you can contact us
directly either by telephone [phone] or by fax +1 (408)
970-9727, someone from the sales department will send you site license
information.

Regards,

Aryeh Goretsky
McAfee Associates Technical Support

- --
McAfee Associates     | Voice [phone]    | [e-mail]  (business)
4423 Cheeney Street     | FAX   [phone]    |
Santa Clara, California     | BBS   [phone]    | [e-mail](personal)
95054-0253  USA         | v.32  [phone]    |
ViruScan/CleanUp/VShield | HST   [phone] | CompuServe:  76702,1714

------------------------------

Date:    Sat, 03 Aug 91 15:54:35 -0400
>From:    [e-mail]
Subject: Scan and Clean problems (PC)

        With regards to those of you who have been writing to say that
        McAfee's Scan v7.6, or 7.7, or 7.XX, don't correctly identify a
        virus, likewise that the v 7.XX of Clean doesn't remove it

        - Why don't you guys get v8.0 of it?  Maybe it works.  This isn't
        a plug for McAfee, this is just what seems to me to be a very
        logical thing to do.  If you are using an out-dated virus
        detector/remover then you should not be surprised when it doesn't
        do what you want it to do.

                          Paul Bradshaw
                          University of Guelph
                          Computer Science

------------------------------

Date:    04 Aug 91 11:39:57 +0000
>From:    [e-mail] (Fridrik Skulason)
Subject: Re: Rip-off software package (PC)

[e-mail] (Jan R. Terpstra) writes:
>Recently it was brought to my attention that a so called ShareWare
>package of anti-virus utitlities is offered by Mauro Bollini of Italy
>at US $45.  After checking a recent copy of the anti-virus package, it
>turns out that it consists of bootlegged copies of several program's
>from Frisk, Alan Solomon, McAfee and my own virscan.dat file.

One good thing about this - we cannot sue him for operating the virus
BBS, but it would be VERY easy to bring a lawsuit against him on the
basis of copyright law....

- -frisk

------------------------------

Date:    Fri, 02 Aug 91 16:34:11 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: re: High memory (PC), "Stealth" (PC), Review the Literature

>From:    Rich <[e-mail]>
>>From:    "William Walker C60223 x4570" <[e-mail]>
>>>From:    [e-mail] (A. Padgett Peterson)

First a comment: while the practise of crediting people with their words
is good, this is the second time recently that I have been credited with
someone else's words. Bill's comments and sources are well taken but they
are his not mine, Mr. Walker was responding to an earlier posting.

>I recently saw a program (and the .ASM source) which goes TSR and
>waits for the user to execute LOGIN (.com, .exe, or .bat).  It then
>records everything in a hidden file named TESTING<alt-255>.TMP.

To apply the proper term, this is a SPOOF and such have been known in the
mainframe world for years.

>Now, taking this into account, couldn't a virus be written which would
>place itself in that memory you were talking about, and remain undetectable
>to the methods you were describing above?  It could scan for HIMEM.SYS,
>QEMM, etc, and if it finds one being executed, move itself to conventional
>memory (where it COULD be detected, but won't, since you've already scanned
>it with the pre-D thing) and then load the memory driver?

First, a TSR must take memory from somewhere and so far this has been
fairly redily detectable (usually just with CHKDSK). Second, it must
take control of some normally executed code. This is also detectable by
a reasonably well-engineered integrity management routine.

>One other point:  I got to thinking earlier today (uh oh!).... Since
>you can re-write the BIOS table to intercept interrupts (e.g. int 09h
>is intercepted by SideKick, to check for the ctrl-alt key combo),
>this indicates that the BIOS vector is in RAM.  This is copied from
>ROM on bootup, right?  Can't you write a driver (.sys) file to be
>executed in config.sys which would go TSR and then warn you everytime
>a program re-directed an interrupt?

Good thinking except that DOS itself "fixes" a number of interrupts and
adds several "features" that MicroSoft does not care to document that make
use of conventional (i.e. documented) interrupts unnecessary. Your question
about the interrupt table vectors indicates that you should begin with
a review of DOS structures. (e.g. Ray Duncan's "Advanced MS-DOS" -plug)

>file, nor have I seen any information on how to do it.  Can someone
>point me in the right direction so that I can learn how to write one?
>If no one else likes my idea, *I* at least would like it on MY
>system....

See above.

- ------------------------------------------------------------
>From:    Kevin Dean <[e-mail]>
>Subject: Re: Self-scanning executables (PC)

>I have some ideas on how to detect stealth viruses.  I'll test them out
>as soon as I can and post the results here.

Usually CHKDSK is sufficient. Some time ago I wrote a basic paper on the
subject (6 Bytes). Though deliberately somewhat simplistic, it should give
some ideas on how to detect "stealth" and what is necessary for "stealth"
to operate. I believe Ken has it in the Virus-L archives on CERT.

- ----------------------------------------------------------------
>From:    Jeff Boyd <[e-mail]>
Subject: Re: Self-scanning executables (PC)

>The virus must intercept the calls to read the disk image, notice that
>the file is already infected, and replace the interrupt return values
>with "good-looking" data. Will 4096 really do this?

Yes

>If it can, I don't understand how anyone has ever discovered it.

First, many PCs slow waaaaay down when infected, others crash a lot. Secondly,
over 4k of RAM space disappears from CHKDSK and infected files report
problems. The problem is that to hide, the virus has to lie to DOS and this
is a Bad Thing. Many viruses are detectable by looking for what isn't there.

                        Padgett

Disclosure: for financial reasons (why else?), a company I have an interest
  in is an agent for several commercial computer security products, however
  the revenue generated thusfar is insufficient to change my opinions. When
  it is, I'll retire to restoring my Pontiacs.

------------------------------

Date:    15 Jul 91 03:12:00 +0000
>From:    [e-mail] (Brett Simcock)
Subject: re: Can such a virus be written... (PC) (Amiga)

Original to: acdfinn
AA > heard that
AA > Kickstart 2.0 has most AmigaDos commands in ROM (the ROMs
AA > are shipping
AA > now) but I'm not sure.  That would be great from the virus
AA > perspective...

As far as I know all the AmigaDOS commands are in ROM.

- ---
 * Origin: S.A. CENTRAL BBS, Serving South Australia Better! (3:681/859)

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 136]
******************************************
VIRUS-L Digest   Monday,  5 Aug 1991    Volume 4 : Issue 137

Today's Topics:

Infects on ANY access?
Re: FINAL CALL, COMPUTING & VALUES CONFERENCE, AUG 12-16
Re: ME
Re: Proposal for standard virus signatures notation
Re: Info re viruses in shrinkwrap software?
Floppy Door Close TSR? (PC)
Viral operations in brief

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Mon, 05 Aug 91 10:49:00 +1000
>From:    [e-mail]
Subject: Infects on ANY access?

In trying to get myself upto speed on anti-viral techniques I came across the
following.

I quote from "The Complete Computer Virus Handbook", Price Waterhouse, Issue 2,
September 1989 - Appendix 1, Page 19.

Re the boot sector virus "Search" = "Den Zuk" = "Venezuelan".
DESCRIPTION: "It infects through ANY ACCESS TO host diskette. ....."

Now it may be just my understanding and usage of english words, but have I
really missed something about how DIR accesses a floppy disk?

[e-mail]

------------------------------

Date:    26 Jul 91 01:01:40 +0000
>From:    [e-mail] (Andrew McKendrick)
Subject: Re: FINAL CALL, COMPUTING & VALUES CONFERENCE, AUG 12-16

Will it possible to request a copy of the transcript of the this
conference after it has finished????

Andrew@fido

- --- LED 1.00
 * Origin: 520StE... Is Modula-2 wirth it?. (3:681/854.3)

------------------------------

Date:    Sat, 03 Aug 91 17:22:58
>From:    [e-mail]
Subject: Re: ME

>From:    [e-mail]

>I was somewhat taken back with Ross Greenberg's abraisive response
>(issue 125) to my posting (issue 119) about the anti-virus product
>review in the UK magazine PC Plus.  Without plumbing the depths of
>personal abuse I would like to defend myself and respond to a couple
>of the 'criticisms' made.

Sorry: when someone attacks the professional integrity of a man I have
respect for and of a journal I further have respect for, it ticks me
off.

>    My discussion was of the review in PC Plus, not of the similar review
>    recently in the Virus Bulletiin.  However if you are interested; Edward
>    is certainly aware of our product but he did not request a copy for
>    review.  In fact the subject has never come up in our occasional
>    conversations.

Hmmm.  So, then you were aware of activity in the area, had made
Wilding aware of your package but didn't get around to sending him one
for review?  Wilding probably should have requested a copy, but you
should certainly have sent him a copy.  If you want to be included in
reviews, this is a good practice to start following.

>>Ah, but what you write *does* suggest that you have a problem with
>>either Hamilton's credibility or VB's or both.

>My intention was to raise awareness of magazine readers of the possible
>partiality of magazine reviews.  Having seen all issues of VB, and even
>having contributed (at a time when I had no other commercial interest in
>the subject), I have had 2 years to form an opinion.  However I shall
>not force this on anyone, but rather respect that other people's range
>from Ross's unstinting praise (well almost) to outright incredulity.

Not unstinting.  I've had many a complaint about VB, but not about its
integrity.  As for the potential problems with the accuracy of a
review in any pub, I would assume that most readers of this list have
seen many a review of a product in some publication that was totally
off base.  That accuracy is based upon the individual reviewer as
edited by the editor; I've seen some factual errors in VB, but not
incorrect slants.

>I was present at one event that Hamilton subsequently reported on, and
>my recollection differed from his report in only one area; the behaviour
>of Hamilton himself and the subsequent response.  This only underlines
>the lesson I learnt from seeing events and names mangled in local
>newspapers, seek corroboration of any news item that may affect you.

I've been in a pub and witnessedd Mark spill a pint on himself.  That
does not somehow reduce his integrity.

Ross

------------------------------

Date:    Mon, 05 Aug 91 12:27:00 +1200
>From:    "Mark Aitchison, U of Canty; Physics" <[e-mail]>
Subject: Re: Proposal for standard virus signatures notation

[e-mail] (Jan R. Terpstra) writes:
> After lengthy discussions with a number of people, three independant
> authors of virus scanning products and myself (as the keeper of the
> VIRSCAN.DAT virus signature file) have agreed upon a standard notation
> for virus signatures...

Good. A nice wee standard. Now watch someone come along and complicate
it! :-)

I didn't see anything about where the name comes into it. How about
having any line starting with a "#" giving the virus name(s) for the
signature string in the line (or lines) below. Furthermore, the first
name following the hash could be a hashcode (I gave the definition of
my method of hashcodes for boot sectors a while ago - I'll post the
updated algorithm and format, which now includes all sorts of file
types as well as boot sectors and MBR's as soon as possible).

And a "#" in a signature line could allow end-of-line comments.

Also, it might be useful to extend the signatures by including an "@"
to indicate absolute positions, with respect to the start of the file
of boot sector, or offsets from the initial instruction, or the end of
the file, etc.  Such things might not be important now, but could be
in the future, and could make scanning a lot faster.

example...

# This is an imaginary signature file, by [e-mail]; 05-aug-91
#05BXP7B.E1R,      "Stoned (variant 7a)", "PORTUGESE STONED"
@00:00@017B:B40206CD130914
#0TEEGYB.RB0,      "Not harmful, MS-DOS 3.3 immunised by V-Basher 1.2"
17675A6C34D0@007E:17FFFF000023
#X587BG6.37Z-1280, "Dim Revenger virus"
19A6????53CD21ABBADABBAD00
##IF OS=OS/2
- -147:AC??55C9129B       # for code segments >64K
##ENDIF

(What this means is...
*The first line identifies the file; it is taken as a comment, since there are
 no signature lines before the next # line. It would be nice to finish each
 first line with a date, since some methods of transferring files from computer
 to computer cause the date-time stamp to be changed.

* Each field in the hash lines finishes with a comma and one of more spaces,
  except the last.

* If a hashcode is given, it is straight after the "#", otherwise you would
  have a space or spaces (no comma) before the first "name" field. I like to
  leave 17 bytes for the whole hashcode field, so the first name field will
  always start at column 20.

* The first name field is the main, preferred, easily understood, name.

* All name fields are enclosed within quotes (char 34), and end with a comma.
  Probably it is okay having a comma within the quoted field. Most high level
  languages should be happy with that.

* The first letter of the hashcode indicates the type of file -
   0 - F indicate boot sectors,
       G indicates a general file infector - could have any extension
       I indicates an invisible-file (IO.SYS, etc) infector
       M indicates an MBR (Master Boot Record, = Partition Table) virus
       O indicates an overlay file infector (okay, these are rare)
       P indicates a program infector (.COM or .EXE or .PRG or .BAS or whatever)
       R indicates a string to search for in RAM, rather than on disk
       S indicates a .SYS (system device driver) file
       T indicates a text file infector (such as .BAT, or some application
         data files)
       W indicates a worksheet (spreadsheet) infector of some sort
       X indicates a virus that only exists in .EXE files

* Any line starting ##IF specifies a block of signatures, etc to skip unless
  a given environment variable has a given value. If environment variables
  "TOM" (for Top Of Memory), "VER" (for O/S true version number), or "HIDOS"
  aren't found, the program should make up a sensible value for them.

Note that is doesn't hurt if a simple scanner simply ignores any line starting
with "#", or a not-so-simple scanner remembers the last "#" line as a comment
to emit whenever it comes across a file matching a signature. But ultimately,
the signature file's format should remain useful for a long time, and scanners
based on such files could be made to run very fast (by applying a limited range
of scan patterns to some files, for instance, and by working on positional
information).

Comments on my comments are welcome, of course.
TTFN,
Mark Aitchison, Physics, University of Canterbury, New Zealand.

------------------------------

Date:    Sat, 03 Aug 91 17:22:58
>From:    [e-mail]
Subject: Re: Info re viruses in shrinkwrap software?

>From:    [e-mail] (Greg Broiles)
>
>The latest issue of Byte has a cover story on viruses and security software -
>a rather disappointing article, truth be told.  They do some rudimentary
>testing of a few antivirals and come up with a simplistic little
>reccommendations-box.  Blech. :(

I did a tech article for BYTE on viruses a coupla years ago.  Well,
that is I *wrote* a tech article.  What appeared in print was some
horrid random assortment of words with verbs and nouns and everything
except any accurate statements.  What was printed was a "co-authored"
piece, except that the co-author took what I wrote, pulled out things
she didn't understand ("Vectors? They only have direction and
speed...why would an interrupt have a vector?"), wrote a bunch of
inaccurate stuff about Mac's, changed code sequences I used to
identify one virus, decided that she, in her infinite wisdom, would
never have a need to show me the article she destroyed, and printed
it.

My coplaints rose high up into the BYTE masthead -- to the top -- and
were never responded to except with a "Gee, that's something that will
never happen again".  No retraction.  No apology.

Forget about BYTE's technical accuracy, at least with regard to viruses.

Ross

------------------------------

Date:    Mon, 05 Aug 91 11:58:47 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: Floppy Door Close TSR? (PC)

>From:    [e-mail] (Jesse Chisholm AAC-RjesseD)

>    Is there a TSR program available that scans a floppy whenever
>the floppy door closes?  Is it even possible to write one?  Are any of
>you all working on one (McAfee, Padgett, ...)?

Considered this but think it would not be the "best" solution. Unlike
the MAC, a PC does not execute anything merely by vitue of the door
being closed.  Executables have to be invoked by the user (even ANSI
bugs are just designed to induce the operator to issue a command that
was not intended - an executable still has to do the work).

Consequently, there are two choices available that would have
approximately equal value:
1) Detect that a new disk has been placed in the drive & do a full checkout.
   (time-consuming)
2) Examine executables as requested (includes warm-booting).
   (relatively little performance impact)

For the above reasons, I personally prefer #2 and one of the layers on
my personal machines is McAfee's* VShield. As far as I know (& am sure
someone will correct me if wrong), this is the only currently
available software that will trap a warm boot and scan relevant
structures for known viruses before permitting the boot to continue as
well as checking anything requested from the disk.

Since my PCs are running DOS 5.0, I can afford the 25k for three
different anti-viral TSRs that IMHO give me ample protection from
malicious software, known & unknown, no one being considered
sufficient. Just FYI, one goes resident during the BIOS load, one from
CONFIG.SYS, and one from a .BAT file at startup (some other
checking/reporting goes also on but this is not resident).

Since a program to do this already exists and am still on negative
free time, what time that is available is reserved for software that
does not exist (yet).

                        Padgett

Disclosure: * is one of the lines the company I am associated with
handles.  (properly worded, disclosure notices can provide free
advertising, no?)

------------------------------

Date:    Sun, 04 Aug 91 20:36:27 -0700
>From:    [e-mail] (Rob Slade)
Subject: Viral operations in brief

FUNGEN2.CVP   910804

                       Viral operations

Although the "original" definition of computer viral programs
refers to reproduction by attaching to other programs, viri that
act in this manner having been less successful than those that
use other means.  In the personal computer world, boot sector
infectors have been much more effective.  (Examples in the
MS-DOS community are the BRAIN and Stoned viral programs.
Examples in the Mac realm are not as clear, but the WDEF virus
could be said to be a type of boot sector infector, as the WDEF
resource is one that is run automatically as soon as any Mac
disk is inserted, although this has changed under System 7.)

In larger systems, mini and mainframe computers, network and
mail viral programs have, so far, had the greatest impact.  The
Morris/Internet/UNIX worm managed to spread and reproduce using
the facility of networked machines to submit programs to each
other.  (A VMS program, WANK, used many of the same techniques.)
The CHRISTMA EXEC used mainframe mail commands, and the ability
to submit programs by mail, in order to reproduce copies which
eventually flooded the network.

Network and mail viral programs carry, in a sense, their own
payload.  The reproduction of the programs themselves uses the
resources of the hosts affected, and in the cases of both the
Morris and CHRISTMA worms went so far as to deny service to
users by using all available computing or communications
resources.

Most other viral programs seem to be written "for their own
sake".  A kind of electronic graffiti which writes itself on
further walls.  However, even these can do damage, as with the
Stoned virus, which overwrites sections of the FAT with the
original boot sector.  Some appear to be written as pranks, and
others as a kind of advertising, although the potential for
damage from even "benign" viri cannot be considered funny, and
the "advertising" viri probably don't engender much goodwill.

Relatively few viral programs carry a deliberately damaging
payload.  Those which do attempt to erase infected programs or
disks are, fortunately, self limiting.

The last payload, or function, which a viral program may carry,
is some kind of intelligence to enable it to evade detection.
So far the various kinds of evasive action; self-modification,
multiple encryption and "stealth" activity; have not proven to
have any advantageous "survival" characteristics.  In one sense,
this is to be regretted, as it demonstrates that the majority of
computer users are not taking the most elementary precautions to
defend against viral programs.

copyright Robert M. Slade, 1991   FUNGEN2.CVP   910804

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 137]
******************************************
VIRUS-L Digest   Monday, 12 Aug 1991    Volume 4 : Issue 138

Today's Topics:

re: Reply to Virus Bulletin
Re: Floppy Door Close TSR? (PC)
Need info on 1575/1591 virus. (PC)
Re: Infects on ANY access?
Viral operations in brief
Jerusalem Virus (PC)
Re: Infects on ANY access?
Re: Proposal for standard virus signatures notation
Proposal for virus signature notation.
Boot Sector and Terminology (PC)
Viruses in IO.SYS (PC)
Uploads to risc.ua.edu (PC)
computer virus classifications
Code Execution Simulator?

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Mon, 05 Aug 91 21:10:40 +0100
>From:    [e-mail]
Subject: re: Reply to Virus Bulletin

For you chaps across the pond who haven't seen the August Virus
Bulletin yet, a couple of quick notes:

1.  Particularly for those who follow virus-l but don't get VB; Dave Chess's
    public letter (virus-l4 i126) leads the letters page, accompanied by
    editorial apologies.

2.  And for those of you do get VB; my copy is fine but I have heard of
    one subscriber who had blank pages in his copy, so check with the
    publishers if you have a problem.

This was a public informaton broadcast.

Ta ta for now, Anthony Naggs.

------------------------------

Date:    Tue, 06 Aug 91 11:11:00 +1200
>From:    "Mark Aitchison, U of Canty; Physics" <[e-mail]>
Subject: Re: Floppy Door Close TSR? (PC)

[e-mail] (Jesse Chisholm AAC-RjesseD) writes:
> Folks:
>     Is there a TSR program available that scans a floppy whenever
> the floppy door closes?  Is it even possible to write one?  Are any of
> you all working on one (McAfee, Padgett, ...)?

This came up a while ago; basically the answer is that scanning when
the door of the floppy disk drive closes (or a diskette is inserted)
is sometimes possible but inefficient. A better method is to scan when
DOS itself scanns the boot sector (it has code to work out if there is
any chance the diskette has been changed, and uses the change-detect
line if it is there). Such a TSR can be very effective in spotting
viruses before they do any harm to your system, and a good one (in
terms of what it catches, how few "false alarms" it gives, and the
miniscule RAM it uses), is SCANBOOT, available by anonymous ftp from
cantva.canterbury.ac.nz [132.181.30.3], and should be coming out of
comp.binaries.ibm.pc soon.

MArk. Aitchison.

------------------------------

Date:    06 Aug 91 03:12:48 +0000
>From:    [e-mail] (daniel t wesolowski)
Subject: Need info on 1575/1591 virus. (PC)

Hello,

A laptop that had come from Canada was thought to have a virus.  A few
different virus checkers were used to test the laptop and nothing was
found. A few weeks later the virus came alive. We did destroy the
virus, but it did corrupt some programs before its death.  Can this
virus fake out the virus checkers or do we have a nasty floppy disk
floating around the property? Any info/history on the 1575/1591 virus
would be most welcome.

-
 -------------------------------------------------------------------------------
Dan Wesolowski
[e-mail]
[e-mail]
-
 -------------------------------------------------------------------------------

------------------------------

Date:    Tue, 06 Aug 91 09:36:22 +0300
>From:    Tapio Keih{nen <[e-mail]>
Subject: Re: Infects on ANY access?

(quote from Price Waterhouse's book)
>Re the boot sector virus "Search" = "Den Zuk" = "Venezuelan".
>DESCRIPTION: "It infects through ANY ACCESS TO host diskette. ....."
>
>Now it may be just my understanding and usage of english words, but have I
>really missed something about how DIR accesses a floppy disk?

If Den Zuk is resident in memory, and user does DIR on clean,
non-write protected diskette, the virus will infect the disk. But you
can't get Den Zuk in memory any other way than booting from infected
disk. This same thing applies to most boot sector viruses, too.

BTW, there's a mistake in Price Waterhouse's Computer Virus Handbook
under Search (=Den Zuk) entry. It says that Den Zuk survives a warm
re-boot, which it can't do. When user presses CTRL-ALT-DEL, the virus
draws red "DEN ZUKO" text on screen and boots the computer then. But
it won't stay in memory.

- --
Tapio Keih{nen  |  [e-mail]  |  DIO COMES - ARE YOU READY TO ROCK?
Disclaimer: This posting has nothing to do with nic.funet.fi archive server.

------------------------------

Date:    Tue, 06 Aug 91 10:48:38 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: Viral operations in brief

        >From:    [e-mail] (Rob Slade)

        >Although the "original" definition of computer viral programs
        >refers to reproduction by attaching to other programs, viri that
        >act in this manner having been less successful than those that
        >use other means.

        This is something that keeps going back & forth. Certainly at the
        moment, the STONED seems have a lead over the JERUSALEM but  this
        is  a  far cry from being a statistic. Most of what I  have  been
        doing  lately  has  been cleaning J-B and  Sunday  off  of  LANs.

        Certainly  there  are far more "crude" file infectors  than  boot
        infectors  since  they are much easier to write. It may  just  be
        that the difficulty of writing a BSI makes for more "stillbirths"
        and those that do survive "in the wild" tend do spread further.

        As  a consequence, the "average" BSI tends to be more  successful
        than  the "average" file infector and they have received a  boost
        lately though distribution on manufacturers disks, a trend  which
        I hope should soon be curtailed.

        >Examples in the Mac realm are not as clear, but the WDEF virus
        >could be said to be a type of boot sector infector, as the WDEF
        >resource is one that is run automatically as soon as any Mac
        >disk is inserted, although this has changed under System 7.)

        Tend  to  disagree: BSIs run before DOS loads and only  once  per
        boot while the WDEF resource is a part of the OS as  demonstrated
        by the System 7 exclusion, and is invoked often. A better analogy
        would be the Lehigh which goes exclusively after COMMAND.COM  and
        I doubt that anyone will disagree that this is a file infector.

        >In larger systems, mini and mainframe computers, network and
        >mail viral programs have, so far, had the greatest impact.

        This  problem is quickly spreading to the micro arena. In  recent
        months I have had occasion to clean several LANs including one of
        500  clients  and another having 2000+  clients.  The  techniques
        developed to disinfect individual PCs (quarantine and clean)  are
        costly, often ineffective, and are not the One True Solution.

        Other  techniques  that  we have discussed  in  this  forum  that
        involve   authentication  of  the  health  of  a  client   before
        permitting  access  to  the  server  are  IMHO  a  more   elegant
        procedure.

        >The last payload, or function, which a viral program may carry,
        >is some kind of intelligence to enable it to evade detection.
        >So far the various kinds of evasive action; self-modification,
        >multiple encryption and "stealth" activity; have not proven to
        >have any advantageous "survival" characteristics.  In one sense,
        >this is to be regretted, as it demonstrates that the majority of
        >computer users are not taking the most elementary precautions to
        >defend against viral programs.

        Depends  on  your  point of view. The Pakistani  BRAIN  is  still
        providing  a significant number of infections and was  the  first
        "stealth" virus. I suspect that the failure to spread far of most
        is because most of the "stealth" seen so far is easy to detect in
        memory  (most just with CHKDSK) and as implemented  causes  other
        problems by lying to the operating system. e.g. lost clusters and
        cross-linked files.

        On  the  whole, I agree with most of  Mr.  Slade's  observations,
        however  I suspect that the next great threat is going to  be  to
        the   LANs  via  file  infectors  and  unless  steps  are   taken
        immediately  to  protect them, serious disruptions are  going  to
        result.  Fortunately, there are solutions, and  not  particularly
        expensive ones, either in cost or reduced performance, just  they
        are different.

                                                     Padgett

        "A virus does nothing a computer cannot do which makes  detection
        difficult.  However they do things a computer should not  do  and
        this is detectable".

------------------------------

Date:    06 Aug 91 18:34:42 +0000
>From:    [e-mail] (Joseph Mocker)
Subject: Jerusalem Virus (PC)

Hi all,

Got a fairly simple question. Does anyone have any information on what
the Jerusalem version B virus can do? Does anyone know where I can
find out anything about this virus?

Thanks...Joe
- --
- ------------------------------------------------------------------------------
Joe Mocker//USAC//PC-NFS Support :: [e-mail] :: Sun Microsystems Inc.

  :: there's still lofty dreams  ::  meager desires  ::  still sillyness ::

------------------------------

Date:    06 Aug 91 21:40:59 +0000
>From:    [e-mail] (Fridrik Skulason)
Subject: Re: Infects on ANY access?

[e-mail] writes:
>DESCRIPTION: "It infects through ANY ACCESS TO host diskette. ....."
>
>Now it may be just my understanding and usage of english words, but have I
>really missed something about how DIR accesses a floppy disk?

The author probably meant that if the computer is infected, the virus
will infect any diskette which is accessed, not that an infected
diskette could infect the computer regardless of how it was accessed.

- -frisk

------------------------------

Date:    Tue, 06 Aug 91 20:38:32 +0000
>From:    [e-mail] (Peter da Silva)
Subject: Re: Proposal for standard virus signatures notation

[e-mail] (Mark Aitchison, U of Canty; Physics) writes:
> Comments on my comments are welcome, of course.

Well, my only comment is about your comments... :->

Speaking as one who has written lots of dumb little programs to parse
various data files over the years, I do have one suggestion...

> # This is an imaginary signature file, by [e-mail]; 05-aug-91
> #05BXP7B.E1R,      "Stoned (variant 7a)", "PORTUGESE STONED"
> @00:00@017B:B40206CD130914

I would recommand, for parsing simplicity, that comments and data be
syntactically distinct. For example, anything after "//" is a comment...

// This is an imaginary signature file...
#05BXP7B.E1R,  "Stoned (variant 7a)", "PORTUGUESE STONED"
@00:00@017B:B40206CD130914
#0TEEGYB.RB0,      "Not harmful, MS-DOS 3.3 immunised by V-Basher 1.2"
17675A6C34D0@007E:17FFFF000023
#X587BG6.37Z-1280, "Dim Revenger virus"
19A6????53CD21ABBADABBAD00    // random in-line comment.
##IF OS=OS/2
- - -147:AC??55C9129B       // for code segments >64K
##ENDIF

It adds a minor bit of complexity to Really Dumb Parsers. It might be
better to do something like this:

# This is an imaginary signature file...
#!05BXP7B.E1R,  "Stoned (variant 7a)", "PORTUGUESE STONED"
@00:00@017B:B40206CD130914
#!0TEEGYB.RB0,      "Not harmful, MS-DOS 3.3 immunised by V-Basher 1.2"
17675A6C34D0@007E:17FFFF000023
#!X587BG6.37Z-1280, "Dim Revenger virus"
19A6????53CD21ABBADABBAD00    # random in-line comment.
##IF OS=OS/2
- - -147:AC??55C9129B       # for code segments >64K
##ENDIF

Again, Really Dumb Programs simply strip out anything after #. But now
smart programs look at the following character to see how to interpret
that line. ! is a code string, # is a directive, space is just a comment,
and so on.
- --
Peter da Silva; Ferranti International Controls Corporation; [phone];
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"

------------------------------

Date:    Wed, 07 Aug 91 10:58:08 +0700
>From:    "Jan R. Terpstra" <[e-mail]>
Subject: Proposal for virus signature notation.

I have received several comments on the proposal. First let my clarify
the thoughts behind the proposal.

It was ONLY intended to achieve a standard notation method for virus
SIGNATURES and not a proposal for file formats, naming conventions and
other things.  With a standard notation, it is very easy to check if
the signature you have just extracted from a new virus specimen does
not already duplicate the scan string in someone lese's virus report.
Comparing virus signatures from different sources if quite cumbersome
at this time, due to the many different ways people write up their
scan patterns. his usually forces you to do the analysis all over, and
then find out you already had all the info in an entirely different
format.

Also, I have has several suggestions to employ existing techniques
like Regular Expressions commonly used on Unix systems. While that is
a widely used notation, I think the use of regular expressions may
complicate the matter or make the notation too flexible and thus error
prone.

I realize that the proposal I wrote up isn't the only way, nor is it
the best way. But it is simple, straightforward, easy to implement in
just about any scanner program and doesn't rely on obscure algorithms.

Nor is the proposal a "law" telling every anti-virus program must use
this method. Whatever the internal workings of an anti-virus product
are, is up to the author. However, if the product allows the use of
externally supplied data, using a common format for the virus
signatures will prevent the double, triple or quadruple efforts of
converting virus signature data to the different formats used by
various anti-virus products.  And that will free up time to do more
useful things.

The main line is that the info published on detecting viruses should
be usable by as many inti-virus programs possible, without the need to
convert the info.

Jan R. Terpstra

Usual disclaimers implied.

------------------------------

Date:    07 Aug 91 08:26:47 -0400
>From:    "Robert McClenon" <[e-mail]>
Subject: Boot Sector and Terminology (PC)

     Rob Slade notes that viruses are traditionally defined as
fragments of malicious code which attach themselves to programs.  He
notes however that the most successful viruses have not satisfied this
definition because they have been boot sector infectors on the PC
family or start-up resource infectors on the Macintosh.

     One can retain the original definition of viruses while
recognizing Stoned and WDEF as viruses if one defines "program"
expansively.  The boot record is a special-purpose program, as is any
resource contained in the Desktop file.  All viruses attach themselves
to programs.  Special-purpose program infectors have been even more
prolific than application program infectors.

          Robert McClenon
          Neither my employer nor anyone else paid me to say this.

------------------------------

Date:    07 Aug 91 08:26:01 -0400
>From:    "Robert McClenon" <[e-mail]>
Subject: Viruses in IO.SYS (PC)

     The question is asked by Willi Grueber in Virus-L 4.133 whether
IO.SYS can be infected by viruses, and whether any checker exists for
such viruses.  I assume that it is at least theoretically possible for
viruses to infect IO.SYS, although I have not heard of any virus which
infects it.  At least one anti- viral package, Virex-PC, can be
configured to protect IO.SYS, either by verifying its checksum at
startup or by intercepting suspicious writes to IO.SYS or both.  I
have it set up to do both.  Other anti-viral packages should also be
capable of protecting IO.SYS unless they are limited to files with
certain extensions.  However, even a checker which is limited to
certain executable extensions should be able to check *.SYS files,
because some Bulgarian viruses will infect installable device drivers
of type *.SYS.

     There is a risk that IO.SYS viruses can be written.  However, it
is a risk that can be anticipated and contained with a little
foresight.

          Robert McClenon
          Neither my employer nor anyone else paid me to say this.

------------------------------

Date:    Wed, 07 Aug 91 08:52:00 -0500
>From:    James Ford <[e-mail]>
Subject: Uploads to risc.ua.edu (PC)

The following files have been uploaded to risc.ua.edu (130.160.4.7) in
the directory pub/ibm-antivirus:

            vsumx107.zip  - Virus Summary Listing
            vc300ega.zip  - Virus Central (ega version)
            vc300lte.zip  - Virus Central (LITE version)

The directory pub/00uploads is now available for people who wish to upload
files to risc.ua.edu.  Mail must be sent to JFORD informing me of your
your upload.

Below is a listing of files available in pub/ibm-antivirus (list is available
as the file "0files.9108".  If you see something that is out of date, please
let me know.
- ----------
Absence makes the heart go wander.
- ----------
James Ford -  [e-mail], [e-mail]
              The University of Alabama (in Tuscaloosa, Alabama)

- ---------------- file listing of pub/ibm-antivirus on risc.ua.edu ----------
0REVIEWS/      htscan12.zip   unvir902.zip   vc300lte.zip   vstop54.zip
0files.9107    innoc5.zip     uu-help.text   vcheck11.zip   vsum9105.txt
0files.9108    m-disk.zip     uudecode.bas   vdetect.zip    vsumx107.zip
INDEX.291      navupd01.zip   uudecode.pas   virpres.zip    vtac48.zip
MsDosVir.291   netscn80.zip   uuencode.pas   virsimul.zip   wp-hdisk.zip
MsDosVir.690   pcv4.zip       uxencode.pas   virstop.zip    xxdecode.bas
MsDosVir.790   pkz110eu.exe   vacbrain.zip   virusck.zip    xxdecode.c
avs_e224.zip   scanv80.zip    vaccine.zip    virusgrd.zip   xxencode.c
bbug.zip       secur222.zip   vaccinea.zip   virx16.zip     xxencode.cms
clean80.zip    sentry02.zip   validat3.zip   vkill10.zip    zzap54a.zip
fprot116.zip   tbresc12.zip   validate.crc   vshell10.zip
fshld15.zip    trapdisk.zip   vc300ega.zip   vshld80b.zip

------------------------------

Date:    Wed, 07 Aug 91 14:56:16 +0000
>From:    [e-mail] (Igor Smirnov)
Subject: computer virus classifications

Dear colleagues:

I'm system programmer.  I'm interested in a computer viruses problem.
Help me please: What is the PLO viruses?  I've read about that in
Computers&Security.
  I've some ideas for computer virus classification and methods of
anti-virus adaptation.  I would like to know about your interests
in this fields.

 Thank you.

           Sincerely,    Maxim Titov,
                         leading engineer of
                         International Centre on Informatics & Electronics
                         (Moscow, SU)

 Return adress: E-mail: [e-mail],su
                 phone: [phone]

------------------------------

Date:    Wed, 07 Aug 91 18:24:33 +0000
>From:    [e-mail] (Daniel J Karnes)
Subject: Code Execution Simulator?

Working with a new 'virus scanner' program named CES (Code Execution
Simulator) which appears to be an enhanced 'algorithmic' type of
scanner.

The thing is catching 99% of the hundred or so viruses I have tested
against so far with only a few false positives.

Does anyone else have any experience with this thing that they might
like to share?

The distribution file that I have is CES_402.ZIP if anyone happens to
be interested.

- -djk
- -----------------------------------------------------------------
 Daniel J. Karnes - WA6NDT  |  Do I know UNIX?
 [e-mail]      |
 POB 7007                   |  - well.. I've met a few..

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 138]
******************************************
VIRUS-L Digest   Monday, 12 Aug 1991    Volume 4 : Issue 139

Today's Topics:

Introduction to the Anti-viral archives, listing of 07 August 1991
Archive access without anonymous ftp, last changed 30 June 1991
Brief guide to files formats, last changed 30 June 1991
Amiga Anti-viral archive sites, last changed 30 June 1991
Apple II Anti-viral archive sites, last changed 30 June 1991
Atari ST Anti-viral archive sites, last changed 30 June 1991
Anti-viral Documentation archive sites, last changed 10 July 1991
IBMPC Anti-viral archive sites, last changed 30 June 1991
Macintosh Anti-viral archive sites, last changed 30 June 1991
Unix Anti-viral and security archive sites, last changed 30 June 1991

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Wed, 07 Aug 91 10:38:26 -1000
>From:    Jim Wright <[e-mail]>
Subject: Introduction to the Anti-viral archives, listing of 07 August 1991

Introduction to the Anti-viral archives, listing of 07 August 1991

This posting is the introduction to the "official" anti-viral archives
of VIRUS-L/comp.virus.  With the generous cooperation of many sites
throughout the world, we are attempting to make available to all
the most recent news and programs for dealing with the virus problem.
Currently we have sites for Amiga, Apple II, Atari ST, IBMPC, Macintosh
and Unix computers, as well as sites carrying research papers and
reports of general interest.

If you have general questions regarding the archives, you can send
them to this list or to me.  I'll do my best to help.  If you have a
submission for the archives, you can send it to me or to one of the
persons in charge of the relevant sites.

If you have any corrections to the lists, please let me know.

The files contained on the participating archive sites are provided freely
on an as-is basis.

To the best of our knowledge, all files contained in the archives are either
Public Domain, Freely Redistributable, or Shareware.  If you know of one
that is not, please drop us a line and let us know.  Reports of corrupt
files are also welcome.

PLEASE NOTE
The Managers of these systems, and the Maintainers of the archives, CAN NOT
and DO NOT guarantee any of these applications for any purpose.  All possible
precautions have been taken to assure you of a safe repository of useful
tools.

Jim Wright
[e-mail]
JWRIGHT@UHCFHT


------------------------------

Date:    Wed, 07 Aug 91 10:38:56 -1000
>From:    Jim Wright <[e-mail]>
Subject: Archive access without anonymous ftp, last changed 30 June 1991

Archive access without anonymous ftp, last changed 30 June 1991

To get files from the anti-viral archives, you do not need access
to anonymous ftp.  (However, anonymous ftp is generally the preferred
method.)  Below is information on accessing the archive sites using
only email.

                           -=-

One way to get access to the archives is through the BITFTP server
at Princeton.  Send a message to the BITNET address is BITFTP@PUCC
with the body of the message containing the single word HELP.  This
should get you more information, and give you access to any archive
site on the Internet.  Due to excessive loads, this service has been
restricted to BITNET and EARN sites only.  UUCP sites need not apply.

                           -=-

Both the AppleII and the Atari ST archives have mail servers which
provide access to their archives.  You may receive automatic updates
of Macintosh anti-viral programs via email.  See the individual articles
on these sites.

                           -=-

You may also retrieve files from the SIMTEL-20 and the INFO-MAC
archives by using one of the many mail servers which maintain
a shadow archive of these sites.  Send the following message to one
of the listserv sites.

help

See the IBMPC and Macintosh articles for a complete list of servers.


------------------------------

Date:    Wed, 07 Aug 91 10:39:28 -1000
>From:    Jim Wright <[e-mail]>
Subject: Brief guide to files formats, last changed 30 June 1991

Brief guide to files formats, last changed 30 June 1991

 -- The most recent copy of the complete text may be anonymous ftp'd --
 -- from ux1.cso.uiuc.edu (128.174.5.59) in the directory doc/pcnet. --
 -- That file is maintained by David Lemson ([e-mail]).       --
 -- Please do not strip this note from this list when passing it on. --

ARC (.arc)
    This format is most popular on PCs.  Compresses and stores multiple
    files in a single archive.
    PC     - arc 6.00, pk361
    Mac    - ArcMac 1.3c
    Unix   - arc 5.21
    VM/CMS - arcutil
    Amiga  - Arc 0.23, PKAX
    VMS    - arcvms
    Apple2 - dearc
    Atari  - arc 5.21b, pkunarc
    OS/2   - arc2

BinHex (.hqx)
    A Macintosh format.  Converts a binary Mac file, including data and
    resource forks, into an archive of only printing ASCII characters.
    Note that BinHex4.0 will create and decode the ASCII hqx encoding used
    on Usenet, while BinHex5.0 will decode the ASCII hqx encoding but will
    create a non-ASCII binary file.
    PC     - xbin 2.3
    Mac    - BinHex4.0, BinHex5.0
    Unix   - mcvert
    VM/CMS - binhex

binscii ( )
    A favorite Apple2 archive format.
    Apple2 - binscii

Compactor (.cpt)
    A new Macintosh format.  Compresses and stores multiple files in
    a single archive.
    Mac    - Compactor1.21

compress (.Z)
    A Unix format.  Compresses a single file in an archive.
    PC     - u16, comprs16, comp430d
    Mac    - MacCompress3.2A
    Unix   - compress
    VM/CMS - compress
    Amiga  - compress
    VMS    - lzcomp
    Apple2 - compress
    Atari  - compress

LHarc (.lzh)
    This format originated on PCs, and is now popular on Amigas.  Compresses
    and stores multiple files in a single archive.
    PC     - lh113c
    Mac    - MacLHarc 0.41
    Unix   - lharc10
    Amiga  - LHarc
    Atari  - lharc113

LHWarp (.lzw)
    This is an Amiga format.  Compresses and stores an entire floppy in a
    single archive.  Better compression than plain Warp.
    Amiga  - Lhwarp

LU (.lbr)
    This is an old format that originated with CP/M.  It is virtually
    non-existent now.  Collects multiple files into a single archive
    with no compression.
    PC     - lue220
    Mac    - ArcMac 1.3c
    Unix   - lar
    VM/CMS - arcutil
    VMS    - vmssweep

nupack ( )
    A favorite Apple2 archive format.
    Apple2 - nupack

PackIt (.pit)
    An old Macintosh format.  Compresses and stores multiple files in a
    single archive.
    PC     - UnPackIt
    Mac    - PackIt3.1.3
    Unix   - unpit

PAK (.pak)
    An old PC format.  Compresses and stores multiple files in a
    single archive.  Also the name of an Amiga format which produces
    self-extracting archives.  Also the name of a new PC format.
    PC     - pak250
    Unix   - arc 5.21
    Amiga  - PAK 1.0

shell archive (.shar, .sh)
    A Unix format.  Stores multiple files in a single archive without
    compression.
    PC     - unshar
    Mac    - UnShar2.0
    Unix   - sh, unshar
    Amiga  - UnShar
    Apple2 - unshar
    Atari  - shar

Squeeze (._Q_)
    An old PC (CP/M?) format.  Compresses and stores multiple files in a
    single archive.
    PC     - sqpc131
    VM/CMS - arcutil
    Amiga  - Sq.Usq
    VMS    - vmsusq
    Atari  - ezsqueeze

StuffIt (.sit)
    A Macintosh format.  Compresses and stores multiple files in a
    single archive.
    PC     - mactopc
    Mac    - StuffIt 1.6
    Unix   - unsit
    Amiga  - unsit

tape archive (.tar)
    A Unix format.  Stores multiple files in a single archive without
    compression.
    PC     - tar, tarread, pax, pdtar
    Mac    - UnTar2.0
    Unix   - tar
    Amiga  - TarSplit, pax
    VMS    - vmstar
    Atari  - sttar

uuencode (.uu, .uue)
    A Unix format.  Converts a binary file into an archive of only
    printing ASCII characters suitable for mailing.
    PC     - uuxref20
    Mac    - UMCP-Tools1.0
    Unix   - uuencode, uudecode
    VM/CMS - arcutil
    Amiga  - uuencode, uudecode
    VMS    - uudecode2.
    Apple2 - uu.en.decode

Warp (.wrp)
    This is an Amiga format.  Compresses and stores an entire floppy in a
    single archive.
    Amiga  - WarpUtil

xxencode (.xx, .xxe)
    A Unix format.  Converts a binary file into an archive of only
    printing ASCII characters suitable for mailing.  Solves many of
    the problems of uuencode.
    PC     - uuxref20
    Unix   - xxencode, xxdecode
    VM/CMS - xxencode

ZIP (.zip)
    This format is most popular on PCs.  Compresses and stores multiple
    files in a single archive.
    PC     - pkz110
    Mac    - UnZip1.02c
    Unix   - unzip4.01
    Amiga  - PKAZip
    Atari  - pkz101-2

ZOO (.zoo)
    This format is popular on many systems.  Compresses and stores multiple
    files in a single archive.
    PC     - zoo201
    Mac    - MacBooz2.1
    Unix   - zoo201
    VM/CMS - zoo
    Amiga  - amigazoo
    VMS    - zoo201
    Atari  - booz
    OS/2   - booz


------------------------------

Date:    Wed, 07 Aug 91 10:39:59 -1000
>From:    Jim Wright <[e-mail]>
Subject: Amiga Anti-viral archive sites, last changed 30 June 1991

Amiga Anti-viral archive sites, last changed 30 June 1991

beach.gal.utexas.edu
        John Perry <[e-mail]>
        This site can be reached through anonymous ftp.
        The Amiga anti-viral archives can be found in the
        directory [ANONYMOUS.PUB.VIRUS.AMIGA].
        This system is running VMS, not Unix.
        The IP address is 129.109.1.207.

ms.uky.edu
        Sean Casey <[e-mail]>
        Access is through anonymous ftp.
        The Amiga anti-viral archives can be found in /pub/amiga/Antivirus.
        The IP address is 128.163.128.6.

uk.ac.lancs.pdsoft
        Steve Jenkins <[e-mail]>
        Service for UK only; no access from BITNET/Internet/UUCP
        Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
        FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
        Pull the file "help/basics" for starter info, "micros/index" for index.
        Anti-Viral stuff is held as part of larger micro software collection
        and is not collected into a distinct area.

ux1.cso.uiuc.edu
        Mark Zinzow <[e-mail]>
        Lionel Hummel <[e-mail]>
        The archives are in /amiga/virus.
        There is also a lot of stuff to be found in the Fish collection.
        The IP address is 128.174.5.59.


------------------------------

Date:    Wed, 07 Aug 91 10:40:30 -1000
>From:    Jim Wright <[e-mail]>
Subject: Apple II Anti-viral archive sites, last changed 30 June 1991

Apple II Anti-viral archive sites, last changed 30 June 1991

brownvm.bitnet
        Chris Chung <[e-mail]>
        Access is through LISTSERV, using SEND, TELL and MAIL commands.
        Files are stored as
                apple2-l xx-xxxxxx
        where the x's are the file number.

uk.ac.lancs.pdsoft
        Steve Jenkins <[e-mail]>
        Service for UK only; no access from BITNET/Internet/UUCP
        Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
        FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
        Pull the file "help/basics" for starter info, "micros/index" for index.
        Anti-Viral stuff is held as part of larger micro software collection
        and is not collected into a distinct area.


------------------------------

Date:    Wed, 07 Aug 91 10:41:01 -1000
>From:    Jim Wright <[e-mail]>
Subject: Atari ST Anti-viral archive sites, last changed 30 June 1991

Atari ST Anti-viral archive sites, last changed 30 June 1991

atari.archive.umich.edu
        Jeff Weiner <[e-mail]>
        Service via FTP and mail, FTP preferred.
        Login as "anonymous", password is your mail address.
        For instructions on the mail server, send the message
                help
        to <[e-mail]>
        "Index" contains complete listing with descriptions.
        "CompInd.Z" contains same list but is compressed.
        "ls-lR.Z" contains compressed ls -lR listing.
        All anti-viral material is contained in ~atari/utilities/virus
        The IP number for this site is 141.211.164.8, but may change.

twitterpater.Eng.Sun.COM
        Steve Grimm <[e-mail]>
        Access to the archives is through mail server.
        For instructions on the archiver server, send
                help
        to <[e-mail]>

uk.ac.lancs.pdsoft
        Steve Jenkins <[e-mail]>
        Service for UK only; no access from BITNET/Internet/UUCP.
        Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft".
        FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
        Pull the file "help/basics" for starter info, "micros/index" for index.
        Anti-Viral stuff is held as part of larger micro software collection
        and is not collected into a distinct area.


------------------------------

Date:    Wed, 07 Aug 91 10:41:34 -1000
>From:    Jim Wright <[e-mail]>
Subject: Anti-viral Documentation archive sites, last changed 10 July 1991

Anti-viral Documentation archive sites, last changed 10 July 1991

cert.sei.cmu.edu
        Kenneth R. van Wyk <[e-mail]>
        Access is available via anonymous ftp, IP number 192.88.209.5.
        This site maintains archives of all VIRUS-L digests, all
        CERT advisories, as well as a number of informational documents.
        VIRUS-L/comp.virus information is in:
                pub/virus-l/archives
                pub/virus-l/archives/predig
                pub/virus-l/archives/1988
                pub/virus-l/archives/1989
                pub/virus-l/archives/1990
                pub/virus-l/docs
        CERT information is in:
                pub/cert_advisories
                pub/cert-tools_archive

csrc.ncsl.nist.gov
        John Wack <[e-mail]>
        This site is available via anonymous ftp, IP number 129.6.48.87.
        The archives contain all security bulletins issued thus far from
        organizations such as NIST, CERT, NASA-SPAN, DDN, and LLNL-CIAC.
        Also, other related security publications (from NIST and others)
        and a partial archive of VIRUS_L's and RISK forums.

lehiibm1.bitnet
        Ken van Wyk <[e-mail]> new: <[e-mail]>
        This site has archives of VIRUS-L, and many papers of
        general interest.
        Access is through ftp, IP address 128.180.2.1.
        The directories of interest are VIRUS-L and VIRUS-P.

uk.ac.lancs.pdsoft
        Steve Jenkins <[e-mail]>
        Service for UK only; no access from BITNET/Internet/UUCP
        Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
        FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
        Pull the file "help/basics" for starter info, "micros/index" for index.
        Anti-Viral stuff is held as part of larger micro software collection
        and is not collected into a distinct area.

unma.unm.edu
        Dave Grisham <[e-mail]>
        This site has a collection of ethics documents.
        Included are legislation from several states and policies
        from many institutions.
        Access is through ftp, IP address 129.24.8.1.
        Look in the directory /ethics.


------------------------------

Date:    Wed, 07 Aug 91 10:42:05 -1000
>From:    Jim Wright <[e-mail]>
Subject: IBMPC Anti-viral archive sites, last changed 30 June 1991

IBMPC Anti-viral archive sites, last changed 30 June 1991

beach.gal.utexas.edu
        John Perry <[e-mail]>
        This site can be reached through anonymous ftp.
        The IBMPC anti-viral archives can be found in the
        directory [ANONYMOUS.PUB.VIRUS.PC].
        This system is running VMS, not Unix.
        The IP address is 129.109.1.207.

risc.ua.edu
        James Ford <[e-mail]> <[e-mail]>
        This site can be reached through anonymous ftp.
        The IBM-PC anti-virals can be found in pub/ibm-antivirus.
        Uploads to pub/ibm-antivirus/00uploads.  Uploads are screened.
        Requests to [e-mail] for UUENCODED files will be filled
        on a limited basis as time permits.
        The IP address is 130.160.4.7.

uk.ac.lancs.pdsoft
        Steve Jenkins <[e-mail]>
        Service for UK only; no access from BITNET/Internet/UUCP
        Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
        FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
        Pull the file "help/basics" for starter info, "micros/index" for index.
        Anti-Viral stuff is held as part of larger micro software collection
        and is not collected into a distinct area.

ux1.cso.uiuc.edu
        Mark Zinzow <[e-mail]>
        This site can be reached through anonymous ftp.
        The IBMPC anti-viral archives are in /pc/virus.
        The IP address is 128.174.5.59.

wsmr-simtel20.army.mil
        Keith Peterson <[e-mail]>
        Direct access is through anonymous ftp, IP 192.88.110.20.
        The anti-viral archives are in PD1:<MSDOS.TROJAN-PRO>.
        Please get the file 00-INDEX.TXT and review it offline.
        NOTE:
        There are also a number of servers which provide access
        to the archives at simtel.
        WSMR-SIMTEL20.Army.Mil can be accessed using LISTSERV commands
        from BITNET via LISTSERV@NDSUVM1, LISTSERV@RPIECS and in Europe
        from EARN TRICKLE servers.  Send commands to TRICKLE@<host-name>
        (for example: TRICKLE@AWIWUW11).  The following TRICKLE servers
        are presently available: AWIWUW11 (Austria), BANUFS11 (Belgium),
        DKTC11 (Denmark), DB0FUB11 (Germany), IMIPOLI (Italy),
        EB0UB011 (Spain) and TREARN (Turkey).


------------------------------

Date:    Wed, 07 Aug 91 10:42:36 -1000
>From:    Jim Wright <[e-mail]>
Subject: Macintosh Anti-viral archive sites, last changed 30 June 1991

Macintosh Anti-viral archive sites, last changed 30 June 1991

beach.gal.utexas.edu
        John Perry <[e-mail]>
        This site can be reached through anonymous ftp.
        The Macintosh anti-viral archives can be found in the
        directory [ANONYMOUS.PUB.VIRUS.MAC].
        This system is running VMS, not Unix.
        The IP address is 129.109.1.207.

dftnic.gsfc.nasa.gov
        Brian Lev <[e-mail]> <SDCDCL::LEV> <LEV@DFTBIT>
        This site offers the "MacSecure" package, made up of John Norstad's
        Disinfectant, and a pair of locally developed HyperCard stacks:
        Joe McMahon's "Anti-Viral Doc" and Brian Lev's "MacHelper".
        Floppy disk:
                Advanced Data Flow Technology Office
                Code 930.4
                Goddard Space Flight Center
                Greenbelt, MD 20771 (Attn: Brian Lev)
        DECnet Copy from DFTNIC::CLDATA:[ANONYMOUS_FTP.FILES.MAC]
                BinHex (ASCII) format as MACSECURE31.HQX
                binary format as MACSECURE31.SEA
        Anonymous FTP from DFTNIC.GSFC.NASA.GOV (128.183.10.3)
                BinHex (ASCII) format as [.FILES.MAC]MACSECURE31.HQX
                binary format as [.FILES.MAC]MACSECURE3.SIT

ifi.ethz.ch
        Danny Schwendener <[e-mail]>
        Interactive access through DECnet (SPAN/HEPnet):
                $SET HOST 57434  or $SET HOST AEOLUS
                Username: MAC
        Interactive access through X.25 (022847911065) or Modem 2400 bps
        ([phone]):
                # CALL B050 <cr><cr>
                Username: MAC
        Files may also be copied via DECnet (SPAN/HEPnet) from
                57434::DISK8:[MAC.TOP.LIBRARY.VIRUS]

rascal.ics.utexas.edu
        Werner Uhrig <[e-mail]>
        Access is through anonymous ftp, IP number is 128.83.138.20.
        Archives can be found in the directory mac/virus-tools.

scfvm.bitnet
        Joe McMahon <[e-mail]>
        Access is via LISTSERV.
        SCFVM offers an "automatic update" service.  Send the message
                AFD ADD VIRUSREM PACKAGE
        and you will receive updates as the archive is updated.
        You can also subscribe to automatic file update information with
                FUI ADD VIRUSREM PACKAGE

sumex-aim.stanford.edu
        Bill Lipa <[e-mail]>
        Access is through anonymous ftp, IP number is 36.44.0.6.
        Archives can be found in /info-mac/virus.
        Administrative queries to <[e-mail]>.
        Submissions to <[e-mail]>.
        There are a number of sites which maintain shadow archives of
        the info-mac archives at sumex:
        * MACSERV@PUCC            services the Bitnet community
        * LISTSERV@RICE           for e-mail users
        * FILESERV@IRLEARN        for folks in Europe

uk.ac.lancs.pdsoft
        Steve Jenkins <[e-mail]>
        Service for UK only; no access from BITNET/Internet/UUCP
        Terminals : call lancs.pdsoft, login as "pdsoft", pwd "pdsoft"
        FTP       : call lancs.pdsoft, user "pdsoft", pwd "pdsoft".
        Pull the file "help/basics" for starter info, "micros/index" for index.
        Anti-Viral stuff is held as part of larger micro software collection
        and is not collected into a distinct area.

wsmr-simtel20.army.mil
        Robert Thum <[e-mail]>
        Access is through anonymous ftp, IP number 192.88.110.20.
        Archives can be found in PD3:<MACINTOSH.VIRUS>.
        Please get the file 00README.TXT and review it offline.


------------------------------

Date:    Wed, 07 Aug 91 10:43:08 -1000
>From:    Jim Wright <[e-mail]>
Subject: Unix Anti-viral and security archive sites, last changed 30 June 1991

Unix Anti-viral and security archive sites, last changed 30 June 1991

funic.funet.fi
        Jyrki Kuoppala <[e-mail]>
        Accessible through anonymous ftp, IP number 128.214.6.100.
        Directory pub/unix/security contains programs to help in
        security, pub/doc/security contains various documents about
        security in general and unix security (like the worm
        documents)

wuarchive.wustl.edu
        Chris Myers <[e-mail]>
        Accessible through anonymous ftp, IP number 128.252.135.4.
        A number of directories can be found in ~ftp/usenet/comp.virus/*.


------------------------------

End of VIRUS-L Digest [Volume 4 Issue 139]
******************************************
VIRUS-L Digest   Monday, 12 Aug 1991    Volume 4 : Issue 140

Today's Topics:

Virus Implants in DoD Weapons
New DOS and old virus checkers? (PC)
Infects on ANY access?
re: Can such a virus be written... (PC) (Amiga)
Virus article in Byte (PC)
infected files with nonstandard extension (PC)
copyright of infected files
Virus Bulletin search strings (PC)
Re: Self-scanning executables (PC)
Problem cleaning "LIBERTY" virus? (PC)
Re: Brunnstein (CARO) virus catalog files
TRACER (PC)
Proposal for standard virus signatures notation
Stoned at EPO (PC)
New Anti-Virus Consortium Announced
System calls

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    07 Aug 91 20:28:57 +0000
>From:    [e-mail] (David Risler)
Subject: Virus Implants in DoD Weapons

>From the August 1991 "Armed Forces Journal International"

"A draft Pentagon directive that called for implanting a computer
"virus" or software disabling mechanism in every major new US weapon
system - one that could be remotely triggered if the weapon fell into
enemy hands - was under consideration last December at a high DoD
level, a knowledgeable source told AFJI recently...If that is the
case, the device is more likely to function as a variable duration
"enabler"...rather than a disabler that could be remotely activated to
prevent a weapon from being used.  In all likelihood, no decision
regarding implanting either kind of device in advanced weapons will
come before the DARPA provides an assessment to Congress of how best
to handle the issue.  That report is expected on Capitol Hill by
August."

The article goes on to say that this would be great for weapons
exports and that EEPROMS could carry such "Trojan Horses" that could
be activated using electrical signals.
Hmmmmmm.  Comments?

------------------------------

Date:    08 Aug 91 01:08:42 +0000
>From:    [e-mail]
Subject: New DOS and old virus checkers? (PC)

Is there any raeson to worry about problems using some of the standard
antivirus programs (e.g. Scan/Clean, or F-Prot) that have been out for
a while on systems using MS-DOS 5?

To put it another way:
can one safely upgrade to DOS 5, reformat the hard disk to one big
partition, re-install the virus checkers being used before, and still
enjoy the same levels of protection.

(I've noted the earlier suggestions in this group about putting F-driver.sys
the last thing in config.sys. Any other tricks to know about?)

------------------------------

Date:    Wed, 07 Aug 91 11:09:56 -0700
>From:    [e-mail] (Rob Slade)
Subject: Infects on ANY access?

[e-mail] writes:

> Re the boot sector virus "Search" = "Den Zuk" = "Venezuelan".
> DESCRIPTION: "It infects through ANY ACCESS TO host diskette. ....."

It might be helpful to have more of the reference, but I suspect what
they intended to say was that an infected system (ie. the virus is active
in memory) will infect a diskette that is accessed in any way.

And why on earth are you trying to get virus info out of the print media?
 :-)

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Wed, 07 Aug 91 22:43:56 -0400
>From:    cellar![e-mail]
Subject: re: Can such a virus be written... (PC) (Amiga)

[e-mail] (Brett Simcock) writes:

> Original to: acdfinn
> AA > heard that
> AA > Kickstart 2.0 has most AmigaDos commands in ROM (the ROMs
> AA > are shipping
> AA > now) but I'm not sure.  That would be great from the virus
> AA > perspective...
>
> As far as I know all the AmigaDOS commands are in ROM.
>
> - ---
>  * Origin: S.A. CENTRAL BBS, Serving South Australia Better! (3:681/859)

Sorry, but the previous author was more correct than yourself.

   In AmigaDOS, the shell scriptinng commands and some of the utilities have
been moved into ROM, but the core utilities remain on disk, so people can use
their own preferred implementations.

   Besides, the 2.0x "ROMs," so far, are released as Kickstart disks to be
loaded into memory.  Chip releases of 2.04 are not yet available.

Rachel K. McGregor : [e-mail] : {tredysvr,uunet}!cellar!rogue

------------------------------

Date:    Thu, 08 Aug 91 21:10:03 +0000
>From:    Fridrik Skulason <[e-mail]>
Subject: Virus article in Byte (PC)

Byte (August '91) just arrived on my desk, and I read the virus
article with considerable interest.  I was obvious that the authors
are not experts in the area of computer viruses, but there were not
too many serious errors in the article.  The worst was regarding their
selection of viruses.  They wrote:

       "we ran tests using eight of the most pervasive and destructive
        viruses in circulation."

If that had only been true....

The viruses they used were:

    "1701/1704" (Cascade) - Common, but not very destructive.
    "Izrael" (Jerusalem) - Common, and a bit destructive.
    "Musician" (probably Oropax) - Rare, and not destructive at all.
    "Vienna" - fairly common, and somewhat destructive.
    "W13 A/B" and "Jocker" - They must be joking...."the most pervasive
    and destructive viruses in existence" ????

I think Jocker has only been reported once, and it took a long time to
get it to work - in fact, many researchers were not convinced that it was
a virus, until David Chess figured out that the original sample had to be
renamed to WABIKEXE.EXE to get it to infect anything at all.

No stealth viruses, no boot sector viruses, only a few old viruses, which
are certainly not typical of the threats today.

No, a better description of their viruses would have been:

    "we ran tests using eight fairly harmless two year old viruses, half
     of which are practically unknown in the wild."

- -frisk

------------------------------

Date:    07 Aug 91 21:56:30 +0000
>From:    [e-mail] (Warren Burstein)
Subject: infected files with nonstandard extension (PC)

I had a recurring Sunday infection.  I couldn't figure out how Sunday
could be hiding, it turned out that it had latched onto files that did
not end in .COM or .EXE.  (Sunday, at least the version that only
triggers on day-of-week == 7) it turns out, was just lucky, it
assumes that if the file doesn't end with M it's an EXE.

So some other program or programs must be execing these files
directly.  The files are pw.prg (part of Perfect Writer, I guess), and
scomlv3.cmd and scom2v3.cmd (from SmartComm ?).

How common is this?  Should a virus scanner scan all files regardless
of extension against the chance that they might be executed by some
other program?

[Yes, of course they should have been running a TSR.]
- --
/|/-\/-\       The entire world            Jerusalem
 |__/__/_/     is a very strange carrot
 |warren@      But the farmer
/ worlds.COM   is not worried at all.

------------------------------

Date:    07 Aug 91 22:25:14 +0000
>From:    [e-mail] (Warren Burstein)
Subject: copyright of infected files

It occurred to me that anyone who deals with viruses must of course
have a collection of infected files for comparison, dissasembly, and
testing of anti-viral methods.  It would not be surprising for such
people to thereby acquire lots of copies of software that they don't
have licenses for (and what if the virus has a copyright, too :-) ?).
Not that they ever intend to use the software for its intended
purpose, but might the manufactures get upset anyway?
- --
/|/-\/-\       The entire world            Jerusalem
 |__/__/_/     is a very strange carrot
 |warren@      But the farmer
/ worlds.COM   is not worried at all.

------------------------------

Date:    08 Aug 91 13:37:47 +0000
>From:    [e-mail] (Warren Burstein)
Subject: Virus Bulletin search strings (PC)

The sunday virus has two entry points, one for a COM file (0 jumps
to 95), one for an EXE file (at C4).  It happens that the search
string in the Virus Bulletin starts at the COM entry point, which
means that if you were scanning starting at the entry point of
an infecte EXE file, you would not find it.

This is the version of Sunday that never triggers because it
waits until day-of-week is 7.
- --
/|/-\/-\       The entire world            Jerusalem
 |__/__/_/     is a very strange carrot
 |warren@      But the farmer
/ worlds.COM   is not worried at all.

------------------------------

Date:    09 Aug 91 00:38:47 -0400
>From:    Kevin Dean <[e-mail]>
Subject: Re: Self-scanning executables (PC)

CRCSET version 1.3 has been uploaded in UU-encoded form to the
following sites if anyone wants a copy:

risc.ua.edu
ux1.cso.uiuc.edu
wsmr-simtel20.army.mil

------------------------------

Date:    Fri, 09 Aug 91 10:43:00 -0500
>From:    Ken De Cruyenaere 204-474-8340 <[e-mail]>
Subject: Problem cleaning "LIBERTY" virus? (PC)

The LIBERTY virus made another appearance on our campus recently.
CLEAN V80 was unable to clean it though.  I beleive the message
was something like "Unable to clean this file, delete ? y/n "
(Over a dozen infected files and none of them could be cleaned.)

We next tried Central Point's ANTIVIRUS and it cleaned it up
quickly. Central Point identified it as the MYSTIC virus,
which caused a little confusion as MYSTIC isn't listed as
and alias of LIBERTY...
    I have checked back issues of this digest for any other
similar problems with CLEAN (version80) and LIBERTY and didn't
find any.  Has anyone else bumped into this?
  Ken
- ---------------------------------------------------------------------
Ken De Cruyenaere - Computer Security Coordinator
Computer Services - University of Manitoba - Winnipeg, Manitoba, Canada, R3T 2N
2
Bitnet: [e-mail]   Voice:[phone]    FAX:[phone]

------------------------------

Date:    09 Aug 91 03:22:55 +0000
>From:    p4tustin!ofa123.fidonet.org![e-mail] (Ray Mann)
Subject: Re: Brunnstein (CARO) virus catalog files

Are these the early virus catalog files, published elsewhere, or are
they new, recently-produced ones...?

- --- Opus-CBCS 1.14
 * Origin: Universal Electronics, Inc. [714 939-1041] (1:103/208.0)
- --
Ray Mann
Internet: [e-mail]
Compuserve: >internet:[e-mail]

------------------------------

Date:    Fri, 09 Aug 91 12:03:18 -0700
>From:    altos![e-mail] (Jesse Chisholm AAC-RJesseD)
Subject: TRACER (PC)

Does anyone know anything about the antivirus program called TRACER
by a company called GODWARE?  All I know is they are based in Taiwan.

Has anyone had experience with it?  Is it any good?  It certainly is
inexpensive: NT$130 which comes to about $5.

- -Jesse Chisholm        [e-mail]

- --
| "As I was going up the stair
|  I met a man who wasn't there.
|  He wasn't there again today.
|  I think he's with the C.I.A." -- Ann Onymous

------------------------------

Date:    08 Aug 91 01:53:01 +0000
>From:    [e-mail] (garth kidd)
Subject: Proposal for standard virus signatures notation

I like the proposal.

Now, are we going to see publication of, say, lists of virus signatures for the
more common viruses, mayhap in VSUM?

Down: virus writers could use the lists to check that the virus they're writing
doesn't match anything else. Of course, they can use the latest copies of
anti-viral software to check this, but the signatures will tell them =exactly=
what to avoid.

One solution for this is to use two or more different signatures for each virus
in the more wildly popular anti-viral software, but only publish one in VSUM.

Up: people can write quick'n'grotty virus scanners to check to see whether
their system is infected with X without having to find a copy of (say) SCAN
that checks for it. Even if SCAN allowed signature files, (and for all I know,
it does), they might not =have= it.

Email reponses welcome; I'm still not sure whether the gate works in the
fido->usenet direction.
gk

- --- FD 1.99c
 * Origin: [e-mail] (3:680/828)

------------------------------

Date:    Mon, 12 Aug 91 15:45:02 +0100
>From:    [e-mail]
Subject: Stoned at EPO (PC)

New Scientist 10 August 1991, p. 24 under byline "Computers Get Stoned
On Patent Discs" reports that the European Patent Office in Munich has
been sending clients a floppy disc containing the Stoned virus.

The EPO has sepnt nearly #20,000 warning recipients of the disc all
around the world not to use it and helping those who did get rid of
the virus.

The disc causing all the trouble contained publicity samples of an
electronic version of the weekly Bulletin which lists all new patents.

IInApril the EPO sent copies of the disc to 1000 ormore patent agencies
etc. The office has sepnt 3 months tracking down the source of the virus
and now believes it came from an independent software company in Germany
which helped with the preparation of the disc. If it can find firm
evidence it will sue the company.

Iain Noble
- -----------------------------------------------------------------------------
Iain Noble                                   |
[e-mail]                           |  Post:  Main Site Library,
JANET: [e-mail]                    |         Teesside Polytechnic,
EARN/BITNET: LBA002%pa.tp.ac.uk@UKACRL       |         Middlesbrough,
INTERNET: [e-mail] |         Cleveland, UK, TS1 3BA
UUCP: [e-mail]            |  Phone: [phone]
- -----------------------------------------------------------------------------

------------------------------

Date:    Mon, 12 Aug 91 09:21:00 -0600
>From:    "Rich Travsky [phone]/3668" <[e-mail]>
Subject: New Anti-Virus Consortium Announced

The August 5th Network World has an article on a new consortium: The
AntiVirus Product Developers Consortium (AVPD).  Goals are: establish
standards for reporting, classifying, and counting viruses; adopt a
code of developers ethics; increase the public's awareness; sponsor
research by vendor-independent organizations.  Members currently are:
Central Point Software, Certus International, Symantec/Peter Norton,
and XTree Co.  Membership is open to all other vendors.

AVPD will rely on a virus database operated and maintained by the NCSA.
This database currently has about 900 viruses.

First AVPD meeting is scheduled for Nov. 25-26 in Washington DC.

Richard Travsky
Division of Information Technology     RTRAVSKY @ CORRAL.UWYO.EDU
University of Wyoming                  (307) 766 - 3663 / 3668

------------------------------

Date:    Sun, 11 Aug 91 18:22:57 -0700
>From:    [e-mail] (Rob Slade)
Subject: System calls

FUNGEN3.CVP   910811

                Viral use of operating systems

Viral programs use basic computer functions in more ways than
one.  It is easier to use standard system calls for purposes
such as accessing disks and writing files or formatting.  Most
programs use the standard operating system calls, rather than
write their own system function when "using" the hardware.  For
one thing, it's more "polite" to do this with applications
programs, which, if they follow "the rules" will be better
"behaved" when it comes to other programs, particularly resident
programs and drivers.  But it is also easier to use system
functions than write your own.

Operating system functions are generally accessible if you know
the memory address at which the function starts, or the specific
"interrupt" that invokes it.  Viral programs can use this fact
in two possible ways.

The first is to use the standard system calls in order to
perform the copying, writing or destructive actions.  This,
however, has unfortunate consequences for the viral author (and
fortunate for the computer community) in that it is easy to
identify these system calls within program code.  Therefore, if
viral programs used only this method of operation, it would be
possible to write a "universal" virus scanner which would be
able to identify any potentially damaging code.  It would also
be possible to write programs which "trapped" all such system
calls, and allowed the user to decide whether a particular
operation should proceed.  (In fact, in the MS-DOS world, two
such programs, BOMBSQAD and WORMCHEK, are available, and were
used to check for early trojan programs.)

Operating systems are, however, programs, and therefore it is
possible for any program, including any viral program, to
implement a completely different piece of code which writes
directly to the hardware.  The "Stoned" virus has used this very
successfully.

Unfortunately, viral programs have even more options, one of
which is to perform the same "trapping" functions themselves.
Viral programs can trap all functions which perform disk access
in order to hide the fact that the virus is copying itself to
the disk under the "cover" of a directory listing.  Viral
programs can also trap system calls in order to evade detection.
Some viri will "sense" an effort to "read" the section of memory
that they occupy, and will cause the system to hang.  Others
trap all reading of disk information and will return only the
"original" information for a file or disk: the commonly named
"stealth" viral technology.

copyright Robert M. Slade, 1991   FUNGEN3.CVP   910811

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 140]
******************************************
VIRUS-L Digest   Thursday, 15 Aug 1991    Volume 4 : Issue 141

Today's Topics:

re: infected files with nonstandard extension (PC)
Re: New Anti-Virus Consortium Announced
SAM Exceptions crashes my Mac (Mac)
WANTED: Master Index of IBM-PC Viruses (PC)
Viruses in Weapons Systems
Bus Error, Teenager Abuse (Mac)
re: Virus Implants in DoD Weapons
8 tunes virus
DOS memory mangement (PC)
NetWare boot process (PC)
Revised Product Test - - Virucide, Version 2.24
Product Test - - TbScan

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    12 Aug 91 16:40:15 -0400
>From:    "David.M.Chess" <[e-mail]>
Subject: re: infected files with nonstandard extension (PC)

>From:    [e-mail] (Warren Burstein)
> ...
>How common is this?  Should a virus scanner scan all files regardless
>of extension against the chance that they might be executed by some
>other program?

We advise users of the IBM Virus Scanning Program to use the -a
option during cleanup; that says to scan all files.   (We also
advise the use of -g, which says to report all signatures
everywhere, boot signatures in files, EXE signatures in COM-format
files, and so on; during cleanup.)

In general, unless you have a very critical system, I think this
is the right balance.   If you have an active infection, it's
going to infect *some* *.EXE or *.COM file (or one of the other
extensions we scan for by default), and then you'll know that
you should scan everything else, too.

DC

------------------------------

Date:    Mon, 12 Aug 91 20:36:16
>From:    [e-mail]
Subject: Re: New Anti-Virus Consortium Announced

>From:    "Rich Travsky [phone]/3668" <[e-mail]>
>
>The August 5th Network World has an article on a new consortium: The
>AntiVirus Product Developers Consortium (AVPD).....
> Members currently are:
>Central Point Software, Certus International, Symantec/Peter Norton,
>and XTree Co.  Membership is open to all other vendors.

There was a meeting held very recently of a so-called "steering
committee".  I believe the members of the steering committee include
Central Point, Certus, McAfee, Microcom and Symantec.

>AVPD will rely on a virus database operated and maintained by the NCSA.
>This database currently has about 900 viruses.

I would be interested in finding out what viruses they have.  The best
I can consider is that they are counting COM's and EXE's as different
viruses and counting minor varients of viruses as new/different ones,
two.

Ross

------------------------------

Date:    13 Aug 91 16:15:48 +1100
>From:    [e-mail] (Nick Guoth)
Subject: SAM Exceptions crashes my Mac (Mac)

Hi,

  We have just received our update to SAM 3.0.1 and have found a problem.
If we try to look at the 'exceptions' in the SAM Intercept then the
Macintosh crashes. Also, we have another copy on a IIsi, and because of
this crash (IMO), it continues to ask por permission to allow the
Moire cdev on startup - i.e. it ignores the Learn button. This does not
happen on the other Macs.
  Someone mentioned that there is now a version upgrade of 3.0.3. Is
this true?
  Any help would be greatly appreciated.
  Please e-mail to me on either of the addresses below.

/-----------------------------------------------------------------\
nick guoth       [e-mail]   or   [e-mail]
Research School of Chemistry      Computing Unit
Australian National University    Canberra, AUSTRALIA
"Happiness is a piece of fudge caught on the first bounce" - Snoopy
\-----------------------------------------------------------------/

------------------------------

Date:    Tue, 13 Aug 91 04:29:28 +0000
>From:    [e-mail]
Subject: WANTED: Master Index of IBM-PC Viruses (PC)

  Greetings! Is there a "master index" of all the viruses ever made for
the IBM-PC's (and compatibles)? I'm preparing a report on different virus
strains created for IBM-compatible machines, and I'd like to use the info-
rmation to add to my report.

  If such a "master index" is not available, could someone lead me to an
FTP site w/ virus reports (and descriptions of what the viruses affect/
destroy/change)?

  Thanx!

Tom Claydon

------------------------------

Date:    Tue, 13 Aug 91 15:59:39 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: Viruses in Weapons Systems

        >From the August 1991 "Armed Forces Journal International"

        >"A  draft  Pentagon  directive  that  called  for  implanting  a
        >computer  "virus" or software disabling mechanism in every  major
        >new  US weapon system - one that could be remotely  triggered  if
        >the weapon fell into enemy hands

        Sounds like media hype - there are lots better ways to deactivate
        a  system than with a virus. A few years ago I was involved in  a
        program  to allow high-tech (for the time) system to be  sold  to
        people  we had reason to believe would try to "reverse  engineer"
        the  software. Some special hardware was used to prevent this.  A
        virus is software and is only effective if executed, something  a
        professional can detect and avoid.

                                                               Padgett

 -----------------------------------------------------------------------

        To: Virus-L
        Fm: Padgett Peterson <[e-mail]>
        Da: 13 Aug. 1991
        Su: infected files with nonstandard extension (PC)

        >From:    [e-mail] (Warren Burstein)

        >I had a recurring Sunday infection.  I couldn't figure out how Sunday
        >could be hiding, it turned out that it had latched onto files that did
        >not end in .COM or .EXE.

        What  the virus is looking for is an MSDOS "spawn" action, not  a
        particular  extension  so it can infect anything  that  executes.
        Just because COMMAND.COM will only execute .EXE & .COM files does
        not  mean  that the CPU will not. The good news is  that  I  have
        never seen an infection that had not infected at least some  .COM
        or  .EXE  files  so intitial scanning may be  confined  to  these
        (plus  .SYS and .OV*). Once detected though, the only way  to  be
        sure of eradication is to check everything.
                                                               Padgett


 -------------------------------------------------------------------------

        To: Virus-L
        Fm: Padgett Peterson <[e-mail]>
        Da: 13 Aug. 1991
        Su: Problem cleaning "LIBERTY" virus? (PC)

        >From:    Ken De Cruyenaere 204-474-8340 <[e-mail]>

        >CLEAN V80 was unable to clean it though.  I beleive the message
        >was something like "Unable to clean this file, delete ? y/n "
        >(Over a dozen infected files and none of them could be cleaned.)

        >We next tried Central Point's ANTIVIRUS and it cleaned it up
        >quickly.

        This  is  a  good reason not to rely on just  one  product  -  my
        preference is a layered approach with at least three levels,  one
        normal  and  two dis-similar backups. If a product  is  not  sure
        that a file can be cleaned, it is often better for it not to try.

                                                          Padgett
 -----------------------------------------------------------------

        To: Virus-L
        Fm: Padgett Peterson <[e-mail]>
        Da: 13 Aug. 1991
        Su: Stoned at EPO (PC)

        >From:    [e-mail]

        >New Scientist 10 August 1991, p. 24 under byline "Computers Get Stoned
        >On Patent Discs" reports that the European Patent Office in Munich has
        >been sending clients a floppy disc containing the Stoned virus.

        This  type of thing just keeps happening both here and  abroad  -
        where are all the lawyers when we need them ?

                                                     Padgett
 -----------------------------------------------------------------------

        To: Virus-L
        Fm: Padgett Peterson <[e-mail]>
        Da: 13 Aug. 1991
        Su: New Anti-Virus Consortium Announced

        ><[e-mail]>

        >The August 5th Network World has an article on a new consortium:
        >The AntiVirus Product Developers Consortium (AVPD)...

        >Members   currently   are:  Central   Point   Software,   Certus
        >International, Symantec/Peter Norton, and XTree Co.   Membership
        >is open to all other vendors.

        Haven't  heard  of it but the membership sounds more  related  to
        advertising budgets if more details are available, would like  to
        know. On the subject, I was told last week that the next  release
        of  NAV will just use a single checksum file (like  Engima-Logic)
        rather than the innumerable 77 byte _whatevers.


 Padgett

------------------------------

Date:    13 Aug 91 23:15:27 -0400
>From:    "Robert McClenon" <[e-mail]>
Subject: Bus Error, Teenager Abuse (Mac)

     A message was posted on a customer's bulletin board system (of
which I am the sysop) asking about a problem on a member's Macintosh.
The author's daughter had complained that the Macintosh reported a
"Bus Error".  She then switched off the Macintosh.  When the author
turned it on, he had problems with the various options of the Control
Panel.  He also noticed that the System file had increased in size by
2.6M from its previous size on a backup diskette.  Both I and another
knowledgable participant in the bulletin board suggested that the most
likely cause of this behavior (growth in System file, altered behavior
of displays) was a virus.  The author said that he had used Apple's
virus scanner and did not think he had a virus.  He then added that
his daughter had been copying some sound at the time of the "Bus
Error".  Since sound effects and sound recordings are installable into
the System file, this explains almost everything.  The growth in the
System file is not a virus-like anomaly but an adolescent anomaly,
caused by the daughter installing sound.

     What caused the "Bus Error"?  Is this a hardware error with the
SCSI bus (which could have messed up the Control Panel)?  Should he
have his machine checked out?

          Robert McClenon
          Neither my employer nor anyone else paid me to say this.

------------------------------

Date:    Wed, 14 Aug 91 04:40:00 +0000
>From:    William Hugh Murray <[e-mail]>
Subject: re: Virus Implants in DoD Weapons

>The article goes on to say that this would be great for weapons
>exports and that EEPROMS could carry such "Trojan Horses" that could
>be activated using electrical signals.
>Hmmmmmm.  Comments?

Since, you would not likely know which instance of such a weapon was
aimed at you, and since you might have little time to react, they
would all have to be triggered the same.  Since you would not have
much time to react, the triggering value would have to be widely
disseminated.  Such a widely disseminated value would be disclosed and
could then be used by an enemy to disarm weapons still in your hands.

This could be compensated for in part by distributing the disabling
value in a secure smart card.  This could discourage its replication,
and possibly even prevent its unauthorized use.

Any country known to be employing such a mechanism, even thought to be
employing such a mechanism, would be considered an unreliable source
for arms.  The very idea must already have had a chilling effect on
the arms trade.

William H. Murray

------------------------------

Date:    Wed, 14 Aug 91 13:07:14 +0000
>From:    [e-mail] (Lee Ritter)
Subject: 8 tunes virus

Anybody know what the 8 tunes virus does?. I Have found this on some
software that I have.

Lee

------------------------------

Date:    13 Aug 91 17:28:07 -0400
>From:    Kevin Dean <[e-mail]>
Subject: DOS memory mangement (PC)

Would there be any reason (apart from Frodo/4096 and its ilk) for
there to be a difference between the amount of memory reported by BIOS
and the amount of memory calculated by walking the DOS MCB chain?  Are
there any utilities that would have a (legitimate) reason to take over
a portion of high memory and fiddle with the DOS MCB chain?

------------------------------

Date:    Wed, 14 Aug 91 14:16:42 -0600
>From:    [e-mail] (Kevin Hemsley)
Subject: NetWare boot process (PC)

I am doing research for a paper on virus protection for LANs.  I need
information on booting under NetWare.  I haven't been able to find any
information about the boot record and if/how it is different from a
normal DOS boot record.  Also, if anyone has any information on
previously published papers dealing with virus protection on a LAN, I
would appreciate hearing from you.  Thanks in advance.

-
 -------------------------------------------------------------------------------
 Kevin Hemsley                             |
 Information & Technical Security          | If you think that you have someone
 Idaho National Engineering Laboratory     | eating out of your hand, it's a
 [phone]                            | good idea to count your fingers!
 [e-mail]                              |
-
 -------------------------------------------------------------------------------

------------------------------

Date:    Thu, 01 Aug 91 10:28:29 -0600
>From:    Chris McDonald ASQNC-TWS-R-SO <[e-mail]>
Subject: Revised Product Test - - Virucide, Version 2.24

******************************************************************************
                                                                          PT-12
                                             June 1990
                                    Revised August 1991
*******************************************************************************

1.  Product Description: VIRUCIDE is a commercial anti-virus program to  detect
and  to repair known computer viruses for the MS-DOS computer environment.  The
report addresses version 2.24, released 21 May 1991.

2.  Product Acquisition: The product is available from Parsons Technology, Inc.
The  address  is  Parsons  Technology, Inc., 375 Collins Road NE, Cedar Rapids,
Iowa 52401.  The company has a toll free  number  for  orders,  1-800-223-6925.
The  cost  of  a  single  copy,  as of 31 July 1991, was $49.00.  Each of three
program upgrades , to include version 2.24, have  been  $15.00  which  includes
shipping and handling.

3.   Product  Tester:  Chris  Mc  Donald, Computer Systems Analyst, Information
Systems Command, White Sands Missile Range, NM 88002-5506, DSN  258-4176,  DDN:
[e-mail] or [e-mail].

[Ed. The remainder of this review, and other reviews by Chris McDonald
and Robert Slade, is available by anonymous FTP from cert.sei.cmu.edu
(ip#=192.88.209.5) in the pub/virus-l/docs/reviews directory.]

------------------------------

Date:    Wed, 14 Aug 91 12:28:26 -0600
>From:    Chris McDonald ASQNC-TWS-R-SO <[e-mail]>
Subject: Product Test - - TbScan

*******************************************************************************
                                                                          PT-39
                                      August 1991
*******************************************************************************


1.  Product Description:  TbScan is a copyrighted program written to detect
computer viruses and malicious programs for MS-DOS environments.

2.  Product Acquisition:  The program documentation states that TbScan
"can be used for free in non-commercial organisations and by private users.
Government and commercial organisations have to register the usage of TbScan".
There is a registration form included which describes costs, to include
multiple copy acquisitions.  Frans Veldman is the program author.  The
documentation gives the following address for more information:  ESaSS B.V,
P.O. Box 1380, 6501 BJ Nijmegen, The Netherlands.  The author has registered
the copyright and made the program available on many bulletin boards and
software repositories, to include the MS-DOS repository on simtel20 [192.88.
110.20].  The current path on simtel20 is pd1:<msdos.trojan-pro>tbscan28.zip.
On simtel20 the number "28" in the zipped file denotes version 2.8.  One will
also require a virus signature data file supplied by Jan Terpstra.  The path on
simtel20 is pd1:<msdos.trojan-pro>vs910731.zip.  This denotes a signature file
of 31 July 1991.  Since the signature file is updated frequently, users should
recognize that the path can change.

3.  Product Tester:  Chris Mc Donald, Computer Systems Analyst, Information
Systems Command, White Sands Missile Range, NM 88002-5506, DSN:  258-4176, DDN:
[e-mail] or [e-mail].

[Ed. The remainder of this review, and other reviews by Chris McDonald
and Robert Slade, is available by anonymous FTP from cert.sei.cmu.edu
(ip#=192.88.209.5) in the pub/virus-l/docs/reviews directory.]

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 141]
******************************************
VIRUS-L Digest   Friday, 16 Aug 1991    Volume 4 : Issue 142

Today's Topics:

Re: Problem cleaning "LIBERTY" virus? (PC)
When can a virus infect (AMIGA)
Re: Virus Bulletin search strings (PC)
Mutation engine available (PC)
Smithsonian Virus (PC)
Hard disk locking ? (PC)
Re: Code Execution Simulator? (PC)
NEW VIRUS? (PC)
Re: 8 Tunes
re: OS/2 Viruses (PC) (OS/2)
Self-scanning executables (PC)
More about the mutation engine (PC)
Re: Bus Error, Teenager Abuse (Mac)
HELP - possible virus (IBM 5150?)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Thu, 15 Aug 91 11:26:00
>From:    "Johnwee Lee" <[e-mail]>
Subject: Re: Problem cleaning "LIBERTY" virus? (PC)

[e-mail] (Ken De Cruyenaere 204-474-8340) writes:
> The LIBERTY virus made another appearance on our campus recently.
> CLEAN V80 was unable to clean it though.  I beleive the message
> was something like "Unable to clean this file, delete ? y/n "
> (Over a dozen infected files and none of them could be cleaned.)
>
> We next tried Central Point's ANTIVIRUS and it cleaned it up
> quickly. Central Point identified it as the MYSTIC virus,
> which caused a little confusion as MYSTIC isn't listed as
> and alias of LIBERTY...
>     I have checked back issues of this digest for any other
> similar problems with CLEAN (version80) and LIBERTY and didn't
> find any.  Has anyone else bumped into this?
>   Ken

  Recently, I was also given a disk from a friend that was infected
with the LIBERTY virus. I am also having the same problem trying to
remove it....  If anyone has any idea of cleaning or removing it
without replacing the infected files please kindly let me know.

  I appreciate any help that is available.

   Johnwee Lee
*==============================================================================
|  Johnwee LEE  Y.K.                                |  Second Year NOVICE
|
|  Internet: [e-mail]                |  Information Processing
|
|  P.O.BOX 589, WILLETTON, WESTERN AUSTRALIA  6155. |  CURTIN UNIVERSITY of
|
|  TEL: [phone]       FAX: [phone]        |     TECHNOLOGY
|
*==============================================================================

------------------------------

Date:    Thu, 15 Aug 91 02:57:13 -0600
>From:    Kevin Kadow <[e-mail]>
Subject: When can a virus infect (AMIGA)

With ZEROVIRUS running, after booting from a TC500 hard drive, I ran
across a newly acquired disk which, upon being inserted, resulted in:

ZeroVirus gave a warning "ColdCapture has been changed!"

options: retry  clear

choosing clear resulted in the warning coming back up in about 1/10 second.

I did a cold start, then switched to VIRUSX...

Upon inserting the suspect disk, VirusX warned: Australian Parasite
detected!

Choosing clear seemed to work, since VirusX went back to sleep. I was
under the impression that a boot-block virus could only start-up if
you booted from an infected disk, not by simple insertion?

When will Australian Parasite be documented in the brunnstein files?
- --
[e-mail]                           kadokev@iitvax (bitnet)
                         My Employer Disagrees.

------------------------------

Date:    15 Aug 91 08:50:57 +0000
>From:    [e-mail] (Fridrik Skulason)
Subject: Re: Virus Bulletin search strings (PC)

[e-mail] (Warren Burstein) writes:
>The sunday virus has two entry points, one for a COM file (0 jumps
>to 95), one for an EXE file (at C4).  It happens that the search
>string in the Virus Bulletin starts at the COM entry point, which
>means that if you were scanning starting at the entry point of
>an infecte EXE file, you would not find it.

This signature was defined before I started as the Technical editor,
so I am only indirectly responsible for it, but I don't quite
understand what you mean by "..you would not find it."  The signature
string is present in all infected .EXE files too - and just look for
the virus in one fixed location does not look very sensibfle to me.

- -frisk

------------------------------

Date:    Thu, 15 Aug 91 14:23:40 +0000
>From:    Fridrik Skulason <[e-mail]>
Subject: Mutation engine available (PC)

The person who calls himself Dark Avenger - the author of the "Eddie"
virus (and others), has just released a "mutation engine" - a skeleton
for constructing encrypted self-modifying viruses.  This program has
been posted in source code form on several virus BBSes, and although
it is not as sohisticated as expected, I would not be surprised if
several viruses build around it would apper in the next few months.

- -frisk

------------------------------

Date:    Thu, 15 Aug 91 10:51:11 -0400
>From:    Peter Kibbee <[e-mail]>
Subject: Smithsonian Virus (PC)

       Has anyone ever herd of the stoned virus referred to as the
Smithsonian Virus? Jack Anderson's column of August 12, 1991,
headlined *Computer Hackers Still Playing Havoc*, contains the
following reference:

       This particular virus even has aliases that include "Hawaii,"
"Marijuana," "New Zealand," "Smithsonian" or "Hamo."

        TIA
                                       Phone:   [phone]
                                       NZPAM001 @ SIVM.BITNET
                                       No pressure, No diamonds

------------------------------

Date:    Thu, 15 Aug 91 15:26:38 +0000
>From:    Fridrik Skulason <[e-mail]>
Subject: Hard disk locking ? (PC)

One person here at the University of Iceland had the misfortune of
having his hard disk trashed by the Spanish Telecom virus recently.
It was possible to trace the source of the infection, but now he wants
some method to prevent anyone from working on his machine while he is
away - for example by asking for a password on boot-up.

This is easily solvable with additional hardware - some machines
include this feature in the BIOS, but it is also possible to get an
add-in card for this purpose.

Software-only solutions are less secure of course, but they are
sufficient in his case.  It is possible to create a small program
which asks for a password when you boot from the hard disk, and cannot
be bypassed simply by booting from a diskette.

My questions:

     #1 I guess that such a program already exists - but I have not yet
        been able to find it.  Does anyone know of something like this ?

     #2 If the answer to #1 is "no", I'll probably write this, and might
        make it available if anybody is interested.  The question is - are
        programs like this a good idea ?  I can imagine some potential
        problems, for example if the hard disk is "protected" in this way,
        without the owner's permission, and if a utility to remove the
        protection is included, it really makes the program rather useless.

- -frisk

------------------------------

Date:    Thu, 15 Aug 91 16:23:58 +0000
>From:    Fridrik Skulason <[e-mail]>
Subject: Re: Code Execution Simulator? (PC)

[e-mail] (Daniel J Karnes) writes:

>The thing is catching 99% of the hundred or so viruses I have tested
>against so far with only a few false positives.

Well - it would be interesting to run it against a larger set -
containing 400-800 viruses or so.  In particular, I would be
interested in seeing how it performs against a similar program of my
own, as I have not been able to obtain anything better than a 95%
detection.  Programs like this are not new - I saw one (Russian or
Bulgarian) in Hamburg last December.  This type of anti-virus programs
has a problem with viruses written in a high-level language, but they
are very efficient in finding most instances of suspicious code.
However - the number of false positives may be unacceptable in many
cases.

- -frisk

------------------------------

Date:    Thu, 15 Aug 91 11:08:00 -0500
>From:    [e-mail]
Subject: NEW VIRUS? (PC)

I want to now if anybody out there has notices or sighths about the HV32 FAKKIR
 virus (PC).

This virus, attacks faster and, unfortunatedly, effective, it can destroy in me
mory the SCAN anti-virus program, an then attacks, as i saw, it seems that the
SCANning process is the activator for the virus actions, i'm not sure about
that.

The way in that he does is as follows:

1.- SCAN detects the virus in memory, then it sends and alert, saying that some
thing strange is happening in the computer's memory, and migth want to turn it
off.

2.- A bozo message appears on the screen saying: "I'm killing the &%$,@... poli
ce program ..."

3.- The speaker beeps uncontrolled

4.- You turn off and on again your machine

5.- You discover that all your files, including those on the sub-directories, h
as been converted to a 144 byte file that contains the message "Fakkir has %$,&
@ this Go-Go file... Ha, Ha, Ha"

It seems that the virus works while the speaker is beeping, so, the faster you
reboot your machine, the more files you prevent from attack.

I was searching for signatures, boot sectors, or any other clue for try to figu
re-out how the virus works, but the attack was very faster, and lethal.

If anybody out there has notices about this abomination, please answer.

Thanks in advance.

Ronnie Nader B.
Pacific National Bank          UCSG Systems Eng. faculty
EcuadorGuayaquil - Ecuador

------------------------------

Date:    Thu, 15 Aug 91 18:41:58 +0600
>From:    [e-mail]
Subject: Re: 8 Tunes

Hello,
  the 8 tunes virus is most probably a german product. It plays 8 tunes
after going resident, provided the infection is 90 or more days old.
The virus will wait for 30 min and then start playing randomly selected
tunes of it's repertoire. Four are german folk, songs two are english songs,
one is garbage, and the last is part of the virus TSR interpreted as
music (garbage too).
  Sincerely
     Christoph Fischer

P.S.: I presume you have the other technical details, if not let me
      know.

Christoph Fischer
Micro-BIT Virus Center
University of Karlsruhe
Zirkel 2
W-7500 KARLSRUHE 1
Germany
[phone] Phone
[phone]  FAX
email: [e-mail]

------------------------------

Date:    Fri, 16 Aug 91 00:50:21 +0700
>From:    [e-mail] (Morton Swimmer)
Subject: re: OS/2 Viruses (PC) (OS/2)

[e-mail] (William J. Caelli) writes:

> There have been a number of questions about whether or not there have
> been any reports of OS/2 viruses - particularly program ( as distinct
> from boot-sector ) viruses. Has anyone got any reports of such OS/2
> viruses.

Nope, not a thing. I suspect that there just are not enough installations
of OS/2 yet, in those areas where virus writers tend to be. When we
looked into the possibility of writing viruses for OS/2 we found
many facinating possibilities, I wont go into here. But, like the
MAC operating system, OS/2 has better self-protection and is far
more complicated to program. I doubt not that we will see an OS/2
virus some day.

Cheers, Morton
Virus Test Center, Hamburg, Germany
..............................................................................
.morton swimmer..odenwaldstr.9..2000 hamburg 20..germany..tel: [phone].
.internet: [e-mail] or [e-mail].
..............to leave only footprints, and take only memories................

------------------------------

Date:    Fri, 16 Aug 91 00:53:05 +0700
>From:    [e-mail] (Morton Swimmer)
Subject: Self-scanning executables (PC)

>From:      [e-mail]

>  If I disassembled/debuged some of the CRC checkers, _I_
>probably could write a virus which checked for (some variants) of
>those checkers and modified its infections accordingly; if I didn't

Or you could just destroy the checksum as the Tequila virus did to the
McAfee authentication codes on files.

Cheers, Morton
..............................................................................
.morton swimmer..odenwaldstr.9..2000 hamburg 20..germany..tel: [phone].
.internet: [e-mail] or [e-mail].
..............to leave only footprints, and take only memories................

------------------------------

Date:    Fri, 16 Aug 91 00:49:42 +0000
>From:    Fridrik Skulason <[e-mail]>
Subject: More about the mutation engine (PC)

The file below looks strange - but it contains the PKZIPed, xxencoded
comments by Dark Avenger which were included in his new "mutation
engine".

Normally I would ask Vesselin Bontchev for a translation, as the text
is probably in Bulgarian, but I have not been able to reach him.  So,
if there is anybody reading this who...

       ... can display the Cyrillic character set on his/her PC.
and
       ... understands Bulgarian

I would really appreciate a quick translation, as I am planning to write
a bit about this engine for the September edition of the Virus Bulletin.

begin 400 mutate.zip
hI2g1-+c++++4+0c32-ReZkPBeE6++-k2+++8++++HJJIEJF39Y3HHEw+2UAY
h3HMbC1ZeSomRPVw7-U2HBCLqZjQ7ZpPhaXFeq8--icvRqfLcpe-Z7LwPR4nN
h633-zldqOR8ZJzw4QHrfIi0qDQXFdJgZiqrIjwcBTB0Yk6xpnSpy9SiKfhmw
h9VgeDAEw8KbN5vGcw3xFzOeVypyqOtMUFNx4NLFI4x1SGdm1JBcIOggkqDpx
heix-mcPxCvEcTgPrfZ3tqx7xnI54V+ZXTBYiGvicaV+excvivZYNTsdxZoCT
hBUJ74rHeJLhRmaxjqP63wN79eNpLhnduq9BJfHKeRRCzhCjEhQvgf34BWvVZ
h3nTAokPodiUJ3TmUJuAy-GLDdGGIKfPYZgvcVDcl8Cm8LDucREmRZJWJkB43
hJJjte3KL2heqFBlBUXtJ7GK3t3qDGhfoRhqbU8ccyzhNOtz8rZbDZeKo-8qY
hh2+YVTcPEdskofRFxSIUIM1lIYSoBEsGdYuOBcSaU7hKv9dJyutLBSqlNvCe
h6pAmsIo9PcmMAO1V0sQ2YFJLpEsF7cWvvQk3fP-pep8GGztJHGqSD7RrI7bn
hdP2yZRe0Q8rgMuCyfEfeMxdg4FfJRcfbd80CC82rRHm67nraGQCZ2vVCxmoQ
hd+wIRoeLVRe41up9nrrFGxy8qvlA03uV6vnj67dqI9sjMn6loW15cZovhquP
hTr-MM8dfY1wclaJz4ppCWAxFgTeSKVPsNSL8ROg5fTWeD1SmkVKm3TLcKIYj
hOgWKhgXje4sYe0wZNAfdVUnJZt5hjseo8XH9r9R8L3zJF0IpP5sqB2bgarvX
hmpdgzsJ3e1jN2DafDTUfBFSLTGQsXrMpygjKnQfSIGrFTy5hdrHTHppZEu1M
hIVS51EEW-rLYfkdg3CKNvJCpHoA45GcucaqmLhKhdzUKmI5BSxiuRADG9QDc
h+p-9+E68++c++++4+0c32-ReZkPBeE6++-k2+++8++++++++++++6+++++++
W++-BJJF-J2IiEJBBI2g3-U+++++-++2+C++++B20++++++++
+
end

------------------------------

Date:    Fri, 16 Aug 91 00:58:10 +0000
>From:    [e-mail] (Michael Kerner)
Subject: Re: Bus Error, Teenager Abuse (Mac)

Bus errors are not always bus errors.  What I mean by that is that to
me a bus error suggests a hardware problem, which in my experience has
been rarely the case.  Typically the error is caused by an INIT/CDEV
conflict that the user is not aware of.  I have had similar problems
with a specific Mac in my balliwick (I'll kill Stoll if I ever meet
him - can't stop using that word...)  with CDEV transfers back and
forth.  They should try disabling/removing various INITs and CDEVs one
by one and performing the operation.  Then they will probably find out
what was the cause.

The second most common cause of bus errors (in the low numbers) is a
memory problem.  Typically this will arise if the SIMM wasn't inserted
right, or if it has (once in an eclipse that YOU experience) gone bad.

Mikey.
Mac Admin
WSOM CSG            / TRW Inc.
CWRU                / Corporate HQ
[e-mail]

------------------------------

Date:    Fri, 16 Aug 91 04:08:54 +0000
>From:    [e-mail] (FELDHEIM JOHN D)
Subject: HELP - possible virus (IBM 5150?)

   I think I may have a virus, but I'm not sure.  I have an old IBM
model 5150.  Recently, it has been acting weird.  Its running a lot
slower and some files won't run at all.  It has been getting
progressively worse.  A file I ran yesterday won't run anymore today.
Also, the longer its on, the slower it gets.  After ten minutes, its
so slow that I can see lines between screen flashes.  I have been
using my modem to call BBS's and check out files, so its possible that
I picked up a virus somewhere.  I got a copy of Mc so and so's virus
scan program.  When I ran it, it said that I had a Jerusalem virus on
about 25 files.

   Can anyone help me?  I don't want to start cleaning my hard drive
unless I'm sure that I need to.  I'm rather a novice when it comes to
computers, and I would appreciate any help or advice that anyone has.
Please e-mail me with any suggestions.

      Thanks,
               John Feldheim

[e-mail]

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 142]
******************************************
VIRUS-L Digest   Monday, 19 Aug 1991    Volume 4 : Issue 143

Today's Topics:

Forwarded from Dr. Fred Cohen
Re: copyright of infected files
Hoffman Cat. & VSUM.EXE / ftp site ??? (PC)
Double quote char appear all over - virus? (PC)
Re: Self-scanning executables (PC)
Hard disk locking ? (PC), new prices, musings
LAN scanning (PC)
Re: When can a virus infect (AMIGA)
Hard disk password protection (PC)
Proposal for standard virus signatures notation
Bus Error, Teenager Abuse (Mac)
Re: Hard disk locking ? (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Fri, 16 Aug 91 11:12:45 -0400
>From:    Kenneth R. van Wyk <[e-mail]>
Subject: Forwarded from Dr. Fred Cohen

[Ed. Dr. Cohen asked me to relay the following message to VIRUS-L.
Three comments first (mine, not Dr. Cohen's)...  1) Dr. Cohen does not
have a network address, so I typed this in from a FAX (I don't have a
scanner...), hence any typos are undoubtedly mine, not his.  2) I
don't normally offer this "service" (typos notwithstanding), so please
don't ask me to transcribe messages; I did this as a personal favor to
Dr. Cohen.  3) I would be happy to collect any replies to this message
and FAX them to Dr. Cohen.  Any reply received by Friday, 23 Aug 1991
will be included; any received after that will be forwarded to
/dev/null.  Finally, the views expressed here are Dr. Cohen's,
verbatim.]

Dear VIRUS-L readers:

Normally, I do not participate in bulletin boards such as this one
because there is more noise than signal, but I have been looking over
some of the recent comments about my work, and I thought it was about
time to clarify a lot of misperceptions.

   1) All of my books (and my software products) are available through
      ASP Press, which can be reached at PO Box 81270, Pittsburgh, PA
      15217, USA.

   2) The thesis was first published in 1985, and was accepted by the
      committee in 1986.  A much better book for the average computer
      literate reader is "A Short Course on Computer Viruses" (also
      available through ASP Press).

   3) The formal definition of viruses first published in the thesis
      encompasses ALL self-replicating programs, and I never claimed
      (as far as I am aware) to have written the first computer virus.
      I think that I have seen over 20 other authors (some who even
      claim to be legitimate researchers) who have claimed otherwise.
      They shouldn't cite what they haven't read and understood.

   4) I did do the first SCIENTIFIC experiments on the protection
      issues related to viruses.  I also published more than 1/2 of
      the refereed journal articles on viruses, and I derived many of
      the interesting research results on viruses to date.

   5) I resent the network being used for commercial purposes, which I
      felt it is being used for in "describing" features of virus
      defense products.  I think it might even be against the law.  I
      find it interesting that when someone asks where to get a copy
      of my thesis, they get met with solicitations regarding other
      books on the subject.  I'm not sure, but I think soliciting this
      way on the net is against the law.

   6) Thank you Dave Chess for providing relatively factual
      information to this forum.  I think you guys at IBM should be
      congratulated for your fine work on analyzing virus spread in
      the last DPMA conference and putting the foolishness brought on
      by people who make unsupportable assumptions into proper
      perspective.

   7) Thank you in advance Ken, for posting this for me.  [Ed. You're
      welcome.]

                        Fred (no network address - try ASP Press above)

P.S. Anyone that thinks you need a network address to perform useful
work should try turning off the network for a few months and observe
how much more work you get done when you don't have to sift through
all of that noise.      FC

------------------------------

Date:    15 Aug 91 19:27:59 +0000
>From:    [e-mail] (Jesse Chisholm AAC-RjesseD)
Subject: Re: copyright of infected files

[e-mail] (Warren Burstein) writes:
| It occurred to me that anyone who deals with viruses must of course
| have a collection of infected files for comparison, dissasembly, and
| testing of anti-viral methods.  It would not be surprising for such
| people to thereby acquire lots of copies of software that they don't
| have licenses for (and what if the virus has a copyright, too :-) ?).
| Not that they ever intend to use the software for its intended
| purpose, but might the manufactures get upset anyway?

I avoided this problem by writing a small "Hello, world." program in
both .EXE and .COM form.  Once these are infected I rename them to
something appropriate and delete the original program I got the virus
from.  This also saves disk space.  When it comes time for
disassembly, my own code is easy to recognize; no trying to figure out
the distinction between a virus and some vendor's code.
- --
"I woke up one morning, October 23rd.
Riding the range with the 2-U herd.
Come a ti-yi-yippy-yippy-ay yippy-ay.
Come a ti-yi-yippy-yippy-ay." -- from an old song, "The Chisholm Trail"

------------------------------

Date:    16 Aug 91 17:34:38 +0700
>From:    [e-mail]
Subject: Hoffman Cat. & VSUM.EXE / ftp site ??? (PC)

which ftp sites carry:

- - Hoffman Catalog (PC)
- - VSUM.EXE

?????

thanx in advance

bye ....................................................................  Didi

******************************************************************************
*  Universitas Basiliensis                                       InfoCenter  *
******************************************************************************

------------------------------

Date:    Fri, 16 Aug 91 16:46:11 +0000
>From:    [e-mail] (Thomas Wong)
Subject: Double quote char appear all over - virus? (PC)

One of the 386s in our lab has been having a strange problem.  Double
quote characters slowly appears all over the screen.  I've checked the
computer with VirusScan (SCAN 7.6V80)(latest?)  and no virus was
found. Has anyone seen this before? How can I tell if this is a new
(yet to be discovered) virus? What to do?  What to do....

Thomas.

------------------------------

Date:    Fri, 16 Aug 91 18:33:48 +0000
>From:    [e-mail] (Eric Vaitl)
Subject: Re: Self-scanning executables (PC)

    I started thinking about self scanning executables again.
Unfortunately, it was way to easy to write myself a virus which gets
around the whole damn thing. Here is what it does: When the victim
program is activated, the virus gets control. The virus then totally
removes itself from the program on the disk (remember, the victim's
name is in the psp). The virus then hooks itself into the timer
interrupt and the idle interrupt and goes tsr.  Two timer ticks later
a flag is set and on the next idle interrupt the virus loads and
executes the original program. Any self scanning the original program
does won't find anything. About ten minutes after going tsr, the virus
sets another flag. On a following idle interrupt, the virus attacks
two .exe files in the hard disk. It then unhooks the interrupt vectors
and returns it's saved memory to dos.
    I'm not a real whiz at assembler programming and I was able to get
this thing under 2k and write it over the weekend. It will
successfully attack programs using variants of my vscan() function
without being found. I also had it attack a copy of pkz110.exe and it
wasn't found. (Although I haven't checked if pkz110 is actually self
scanning or if it just does a crc on the contained files).
    Anyhow, my point here is that self-scanning executables might be a
dead end and that I just don't think that we should spend too much
time arguing over whether it's best to do a simple checksum or a crc
when, if a virus writer were worried about the subject he could just
bypass the whole thing.

[e-mail]
flames>/dev/nul

------------------------------

Date:    Fri, 16 Aug 91 14:31:00 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: Hard disk locking ? (PC), new prices, musings

>From:    Fridrik Skulason <[e-mail]>
(referring to a friend)
>  ...now he wants some method to prevent anyone from working  on
>his  machine  while  he is away - for example by  asking  for  a
>password on boot-up.

>Software-only solutions are less secure of course, but they are
>sufficient in his case.

> #1 I guess that such a program already exists - but I have  not
>yet  been able to find it.  Does anyone know of  something  like
>this ?

Quite some time ago I wrote DISKSECURE as an experiment. It is  a
technology  demonstrator  rather than a  commercial  product  (no
flames  please) but should do what you ask. It is available  from
several sites or I can send a UUENCODED ZIP over the net.

It is a BIOS level virus detection/block, prevents DOS access  of
the  disk when booted from a floppy (cannot prevent a  cold  boot
without  special BIOS or hardware). Can be booted "bare"  with  a
special maintenance disk (still requires password) for defragging
and  allows  the  user to create a "recovery"  disk  in  case  an
inadvertant boot from an infected floppy corrupts the file.  Once
resident, the MBR, hidden sectors, and Boot Record are  protected
from alteration and BIOS format calls are trapped.

This  forms part of the triad I use personally for protection  of
my  home  machine (DiskSecure, McAfee's  Vshield,  Enigma-Logic's
Virus-Safe) plus some other "home-brew" integrity checkers.

On  another note, I just received the September Computer  Shopper
and  have noticed considerable price erosion taking place  -  two
items I am interested in particular - 386sx Notebooks  (8"x12"x2"
-  6  lbs)  w/2MB RAM and 20 MB hd have been  spotted  with  what
appear  to  be a nice mix of features for  $1699   while  laptops
(larger  & c.a. 13 lbs) with similar features are to be  had  for
around  $1200.

Given  the availability of more memory, up to 100 MB  disks,  and
expansion chassis for other peripherals, we may soon be in for  a
return to the single PC with just a separate keyboard and monitor
at home and the office. Since sub-$1000 386 desktops are already
plentiful and in theory a notebook should be about the same  cost
to manufacture,
On  the other hand, there were two ads for 9600  baud/MNP5/V42bis
modems under $300, both with Rockwell chip sets. Given text/image
transmissions  between  compatable machines, these  can  give  an
effective throughput of 38,400.

I expect a plethora for $200 by years end - already low-line 2400
baud  units  are under $50 and you can't give away  a  1200  baud
modem - my historical collection includes a Racal-Vadic 1200 baud
that had no auto-features and must have cost $700 new (the  power
supply  alone is larger than most modems today) - and it is  less
than  10  years old ! - State of the art 15 years ago was  a  300
baud TI silent 700 with acoustic coupler. Seems like we are on  a
log curve.

What  meaning  does  this  have for Virus-L  ?  Namely,  the  386
platform  and DOS 5.0 is becomming a defacto standard  just  like
the  8088 did. Already some vulnerabilities are being  exploited,
usually by accident (I am told that the next release on prominent
scanners  will  include  the ability to scan  "high"  for  memory
resident viruses.

In  the  last  six  months, the number  of  LAN  infections  have
increased  dramatically and it taskes a different  philosophy  to
protect  a  LAN  than  a individual  client  while  the  rise  of
affordable  9600 baud modems and Notebooks are going to  increase
transmission vectors dramatically.

Will  this result in the Virus that ate Cincinatti ? I doubt  it,
the  statistics  are  that  it is hard to  affect  a  70  million
platform installed base. But to the 100 pc company or 2000 client
LAN that gets hit by something they did not bother to prepare for
-  Hasta la vista, baby. (what about the offsite backups ? -  see
T3).

                                                  Padgett

------------------------------

Date:    16 Aug 91 16:09:55 -0400
>From:    Jon Freivald <[e-mail]>
Subject: LAN scanning (PC)

>   This  problem is quickly spreading to the micro arena. In recent
>   months I have had occasion to clean several LANs including one of
>   500  clients  and another having 2000+  clients.  The techniques
>   developed to disinfect individual PCs (quarantine and clean)  are
>   costly, often ineffective, and are not the One True Solution.
>
>   Other  techniques  that  we have discussed  in  this  forum that
>   involve   authentication  of  the  health  of  a  client before
>   permitting  access  to  the  server  are  IMHO  a  more elegant
>   procedure.

I've written a program that's implemented on our (Banyan Vines) LAN
that does just that -- it's a two part program that works in
conjunction with McAfee's ViruScan.

Part 1 (the shell) the user is *supposed* to include in his
autoexec.bat - it interrogates the system for # of drives, then
executes the McAfee software on all found hard drives.  It updates a
control file after the McAfee software has run successfully.

Part 2 (the "enforcer") is a part of all the users login profile (which
we don't allow them to change) - it checks for proper installation,
then checks the control file -- if it can't find Viruschk (my prog) or
ViruScan, it logs them out with a nasty-gram - if the control file is
too old, it logs them out, initiates the scan & if the scan completes
successfully, brings them back to the login screen...

If anyone's interested, it's Freeware.  The shell is generic (works
with all PC/MS-DOS systems from 2.11 - 5.0), however, the enforcer only
currently supports Banyan Vines 3.xx & 4.xx (I intend to expand this in
the future, but only have access to Vines).  It's available for
download as vchk21.zip either from the Compuserve Banforum or from my
BBS @ [phone] (N,8,1 - 300-2400 + 9600 HST).

Jon Freivald
SSgt, USMC

------------------------------

Date:    16 Aug 91 20:21:56 +0000
>From:    [e-mail] (SCHILDBACH WOLFGANG)
Subject: Re: When can a virus infect (AMIGA)

[e-mail] (Kevin Kadow) writes:

>With ZEROVIRUS running, after booting from a TC500 hard drive, I ran
>across a newly acquired disk which, upon being inserted, resulted in:

>ZeroVirus gave a warning "ColdCapture has been changed!"

>options: retry  clear

>choosing clear resulted in the warning coming back up in about 1/10 second.

>I did a cold start, then switched to VIRUSX...

>Upon inserting the suspect disk, VirusX warned: Australian Parasite
>detected!

>Choosing clear seemed to work, since VirusX went back to sleep. I was
>under the impression that a boot-block virus could only start-up if
>you booted from an infected disk, not by simple insertion?

There is a new virus out that uses a simple but very efficient way of
spreading. It uses the Disk-Validator located in the L/ directory.  It
works this way: The infected disk has a checksum error on it. So as
soon as you insert it, the system will call the Disk-Validator, but
not the one from your L: directory, BUT THE ONE FROM THE df?:L
directory.  This one is infected. So as soon as you just insert the
disk, your system is infected!

It then does some other things as overwriting the Disk-Validator in your
L: directory and so on... I think it will additionally crypt one specific
track when it is written and decrypt it when it is read. The knack is:
As soon as you have removed the virus, you'll have read errors on all
disk inserted while your AMIGA was infected. As long as the virus is ac-
tive, you won't notice.

Wish you good luck desinfecting your computer...

- --- Wolfgang Schildbach

------------------------------

Date:    16 Aug 91 17:15:20 -0400
>From:    Jon Freivald <[e-mail]>
Subject: Hard disk password protection (PC)

>One person here at the University of Iceland had the misfortune of
>having his hard disk trashed by the Spanish Telecom virus recently.
>It was possible to trace the source of the infection, but now he wants
>some method to prevent anyone from working on his machine while he is
>away - for example by asking for a password on boot-up.

>My questions:

>     #1 I guess that such a program already exists - but I have not
>     yet been able to find it.  Does anyone know of something like
>     this ?

Yes, I use and can highly recommend "PC-Vault".

It is software only and has done well in my evolution from an 8088 XT
up through a 386/40 monster with MFM, RLL & ESDI drives being involved
in the upgrade process...  (I've got version 4.1 - no idea what's
current..)

It requests a password on boot (installs via config.sys).  If the
system is booted via floppy disk, the hard disk cannot be accessed
without running a special utility on the PC-Vault diskette (unlike a
couple other programs where you just plain can't access the hard disk
period!).

Here's the info you'll need to order (I have no ties to this company
other than being a one time customer!):

    Johnson Computer Systems, Inc.
    20 Dinwiddie Place
    Newport News, Virginia 23602
    [phone]

If I recall correctly (it's been a couple years!), the cost was about
$20.00 and I was impressed that I received it so quickly (2 days I
think).

They also offer PC-Vault Plus which offers multiple passwords &
directory level access by which password was used.

At the time I called them, they offerred free demo versions (limited to
one character passwords) of both products...

Jon

------------------------------

Date:    09 Aug 91 12:33:04 +0000
>From:    [e-mail] (garth kidd)
Subject: Proposal for standard virus signatures notation

Original to: nl84479
<looks at floor, shuffles feet> Apology for the return address I included in my
origin line in the last message. The actual message header should be correct.
The origin line should read something like:

- --- FD 1.99c
 * Origin: reply-to [e-mail], please. (3:680/828)

------------------------------

Date:    17 Aug 91 23:59:57 -0400
>From:    "Robert McClenon" <[e-mail]>
Subject: Bus Error, Teenager Abuse (Mac)

     I received no less than ten (yes, ten) replies via E-mail to
my inquiry.  I thank those of you who replied.

     The consensus seems to be as follows.  The "bus error" is not
a SCSI bus error but a data bus error, which is really a memory
address error.  This in turn indicates either a buggy program or a
corrupted program.  Some sound utilities are buggy and can cause
various sorts of damage.

     Everyone said that the user's System file and Control Panel
had been trashed and that he should reinstall the System and the
Control Panel.  Several people suggested that he run a hard disk
integrity utility, such as Apple Disk First Aid, SUM Disk Clinic,
or Norton Disk Doctor (for Macintosh), to determine whether there
was further damage.

     One correspondent suggested the use of Suitcase or
MasterJuggler as a way of avoiding putting the music into the
System.

     There seemed to be general agreement that there was no
evidence of a virus, and that bugs in the sound facility were the
explanation.

     Thank you for your replies.

          Robert McClenon
          Neither my employer nor anyone else paid me to say this.

------------------------------

Date:    Mon, 19 Aug 91 10:29:00 +1200
>From:    "Mark Aitchison" <[e-mail]>
Subject: Re: Hard disk locking ? (PC)

[e-mail] (Fridrik Skulason) writes:
> One person here at the University of Iceland had the misfortune of
> having his hard disk trashed by the Spanish Telecom virus recently.
> It was possible to trace the source of the infection, but now he wants
> some method to prevent anyone from working on his machine while he is
> away - for example by asking for a password on boot-up.
>
> Hardware solutions...

The simplest of the lot is to unplug the disk, of course. It all
depends how long you're away from the computer as to whether yanking
out the cable is worthwhile or not. If it is to cover someone leaving
his machine on while going to lunch, etc, then a boot-up password
isn't much help either, of course. The keyboard lock switch supplied
with most modern computers *should* be the answer, but for some reason
they almost all seem to take the same key! Still, there are some
zero-cost hardware solutions.

> Software-only solutions...

I remember hearing about two programs that require a boot-up password
(other than special BIOS'es), and I think both prevent access to the
hard disk when booting from floppy by presenting a "wrong" partition
table. This, of course, can be circumvented by anyone determined
enough (as Norton's NDD does, for instance), but might be good enough.
Although I don't have either program, I can get hold of one of them if
needed tomorrow, and I think there was some talk about the other in
comp.virus within the last month or so.

There are some alternative software solutions...

(1) change CMOS to say there are no hard disks
Advantage: A wee bit more secure
Disadvantage: You have to manually change it, or boot from a special diskette

(2) change CMOS to say there is a much smaller disk, and put all your valuable
data in a partition after that.
Advantages: More convenient boot-up, and probably more secure, since people and
programs might think *no* hard disk is odd and so look for one, but when findin
g
a small disk (i.e. less cylinders) probably would not look any further.
Disadvantage: Could cause confusion if you ever need to take the computer to
the fixit-guys, and will probably upset some anti-virus software... but then
again, so will all of the solutions.

(3) Use Digital Research's DRDOS 5.0, to put passwords on the important files,
e.g. read/write/delete protection on key directories.
Adavantages: "off the shelf" software, can be useful in cases where the
computer is left running at lunch time, etc, plus some other advantages (such
as the ability to select differring levels of protection for different files)
that may or may not be of value.
Disadvantages: Still lets you boot, so people could use int 13 or Norton's
tools etc (not trying to advertise one brand here, its just that people know
what they do - I personally use all sorts of disk editors). Also, depending on
how you organise things such as global passwords, directory permissions, etc,
you may need to keep giving the password or end up with a less secure system.

(4) Encrypt the hard disk.
This mainly makes reading of private data difficult - someone could still ruin
the disk by formatting, etc. Now that I think about it, perhaps that was what
was being discussed recently. (I must get my archives fixed up so I can search
them by keywords!)

(5) Swap drives, so your hard disk is the second hard disk, and there is either
no first hard disk, or a small one as the boot disk (e.g. a cheap faulty disk -
in most large organsiations people eventually accumulate old disks which only
work on one cylinder, or some of the heads are unreliable, etc - all you need
is a boot sector).
Adavantages: I can't really think of any advantages over (1) or (2), except
that under-describing the disk (i.e. the 2nd alternative) depends heavily on
the disk types known to your BIOS.

Discussion welcomed,
Mark Aitchison.

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 143]
******************************************
VIRUS-L Digest   Wednesday, 21 Aug 1991    Volume 4 : Issue 144

Today's Topics:

Re: Hard disk locking ? (PC)
Re: New Anti-Virus Consortium Announced
Re: Problem cleaning "LIBERTY" virus? (PC)
Re: Mutation engine available (PC)
Re: Smithsonian Virus (PC)
Re: Hard disk locking ? (PC)
help identifying virus on PC (PC)
Re: NEW VIRUS? (PC)
Re: Problem cleaning "LIBERTY" virus? (PC)
Re: More about the mutation engine (PC)
Re: Hard disk locking ? (PC)
Re: HELP - possible virus (IBM 5150?)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Mon, 19 Aug 91 14:15:00 +1200
>From:    "Nick FitzGerald" <[e-mail]>
Subject: Re: Hard disk locking ? (PC)

In VIRUS-L Digest V4 #142 Fridrik Skulason <[e-mail]> wrote:

One person here at the University of Iceland had the misfortune of
having his hard disk trashed by the Spanish Telecom virus recently.
It was possible to trace the source of the infection, but now he wants
some method to prevent anyone from working on his machine while he is
away - for example by asking for a password on boot-up.

This is easily solvable with additional hardware - some machines
include this feature in the BIOS, but it is also possible to get an
add-in card for this purpose.

Software-only solutions are less secure of course, but they are
sufficient in his case.  It is possible to create a small program
which asks for a password when you boot from the hard disk, and cannot
be bypassed simply by booting from a diskette.

>My questions:
>
>     #1 I guess that such a program already exists - but I have not yet
>        been able to find it.  Does anyone know of something like this ?

There's one called PC-Lock which is shareware (sort of).  A "demo"
version is available from many FTP sites but it only allows one
character "passwords".  The replacement MBR that this program writes
makes the HD "invisible" if the PC is booted from floppy.  From a brief
play with the "demo" version it seemed to work much as claimed.  I think
it also gives you the option of write-protecting on a partition-by-
partition basis.

Padgett's DiskSecure has the option of password protecting your HD, but
I don't think there has been a "public" release of this yet.  (Certain
extremely abberant HD controllers, like one I own, cause grief to the
operation of DiskSecure and some similar programs.)

>     #2 If the answer to #1 is "no", I'll probably write this, and might
>        make it available if anybody is interested.  The question is - are
>        programs like this a good idea ?  I can imagine some potential
>        problems, for example if the hard disk is "protected" in this way,
>        without the owner's permission, and if a utility to remove the
>        protection is included, it really makes the program rather useless.

The way PC-Lock and DiskSecure work is they allow you to create a
"maintenance" disk, so you can boot from a floppy for various legitimate
reasons (e.g. booting without your disk cache to de-frag).  They also
provide "de-install" programs.  Obviously, neither maintenance disks nor
de-installers should be left near the PC, although the former still
require the user to supply a password.

On the issue of being able to remove the protection, FDISK will do the
trick if the PC's are booted from floppy, as the system still reports
the hardware is present, it's just that DOS doesn't see it.  A
determined hacker will still be able to break in by using something as
sophisticated as Norton's Utility and a bit of low level snooping around
the disk and then repartitioning to his/her best guess at the original
partitioning scheme (FDISK again).

- - -------------------------------------------------------------------------
 Nick FitzGerald, PC Applications Consultant, CSC, Uni of Canterbury, N.Z.
 Internet: [e-mail]        Phone: [phone]

------------------------------

Date:    Sun, 18 Aug 91 18:00:19 +0700
>From:    [e-mail] (Morton Swimmer)
Subject: Re: New Anti-Virus Consortium Announced

[e-mail] (Rich Travsky [phone]/3668) writes:

> The August 5th Network World has an article on a new consortium: The

These people obviously haven't heard of EICAR and CARO yet. It looks
like there will be much work being done doubled. What a waste of time.

Cheers, Morton
..............................................................................
.morton swimmer..odenwaldstr.9..2000 hamburg 20..germany..tel: [phone].
.internet: [e-mail] or [e-mail].
..............to leave only footprints, and take only memories................

------------------------------

Date:    Mon, 19 Aug 91 16:40:00
>From:    "Johnwee Lee" <[e-mail]>
Subject: Re: Problem cleaning "LIBERTY" virus? (PC)

[e-mail] (Johnwee Lee) writes:
> [e-mail] (Ken De Cruyenaere 204-474-8340) writes:
>> The LIBERTY virus made another appearance on our campus recently.
>> CLEAN V80 was unable to clean it though.  I beleive the message
>> was something like "Unable to clean this file, delete ? y/n "
>> (Over a dozen infected files and none of them could be cleaned.)
>>
>> We next tried Central Point's ANTIVIRUS and it cleaned it up
>> quickly. Central Point identified it as the MYSTIC virus,
>> which caused a little confusion as MYSTIC isn't listed as
>> and alias of LIBERTY...
>>     I have checked back issues of this digest for any other
>> similar problems with CLEAN (version80) and LIBERTY and didn't
>> find any.  Has anyone else bumped into this?
>>   Ken
>
>   Recently, I was also given a disk from a friend that was infected
> with the LIBERTY virus. I am also having the same problem trying to
> remove it....  If anyone has any idea of cleaning or removing it
> without replacing the infected files please kindly let me know.
>
>   I appreciate any help that is available.
>
>    Johnwee Lee

     First of all... I would like to express my sincere *THANKS* to
all those people who mailed me their advice and experience on the
above.

     Just then when I was pondering on how to removed the "LIBERTY"
virus, a friend of mine suggested to me on using the SCAN (Version 77)
from McAfee on our LAN Network to try and removed it. I try using SCAN
77 and it detected it.  When I used CLEAN 77, it reported to have
removed it.

     Later on, I tried using SCAN 80 to make sure that the disk was
"clean" and SCAN 80 reported that "No virus was found" !!! Thus I
think that the "LIBERTY" virus that I have was a variant of the
original LIBERTY virus which SCAN 80 fails to removed it safely. As
such, I would recommand to others to try it out with SCAN 77 and CLEAN
77 if CLEAN 80 fails....

     Now that the virus is "removed" successfully, I regret that I
didn't make a copy of it for those interested in diagnosting it.

Thanks you once again...

Johnwee Lee
*=============================================================================*
|  Johnwee LEE  Y.K.                                |  Second Year NOVICE     |
|  Internet: [e-mail]                |  Information Processing |
|  P.O.BOX 589, WILLETTON, WESTERN AUSTRALIA  6155. |  CURTIN UNIVERSITY of   |
|  TEL: [phone]       FAX: [phone]        |     TECHNOLOGY          |
*=============================================================================*

------------------------------

Date:    19 Aug 91 09:06:43 +0000
>From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Mutation engine available (PC)

[e-mail] (Fridrik Skulason) writes:

>The person who calls himself Dark Avenger - the author of the "Eddie"
>virus (and others), has just released a "mutation engine" - a skeleton
>for constructing encrypted self-modifying viruses.  This program has
>been posted in source code form on several virus BBSes, and although
>it is not as sohisticated as expected, I would not be surprised if
>several viruses build around it would apper in the next few months.

Is this the MUTATE.ASM file, which comments you asked me to translate?
If so, this file is quite old (it has been available since long time)
and all viruses that can be created with it will belong to the PHOENIX
family. All of them could be detected with a wildcard scan string.  If
this is indeed the same file (please, confirm it), I can post here
scan strings that are compatible with SCAN and HTScan/TbScan(X).

Regards,
Vesselin

------------------------------

Date:    19 Aug 91 09:11:41 +0000
>From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Smithsonian Virus (PC)

[e-mail] (Peter Kibbee) writes:

>       Has anyone ever herd of the stoned virus referred to as the
>Smithsonian Virus? Jack Anderson's column of August 12, 1991,
>headlined *Computer Hackers Still Playing Havoc*, contains the
>following reference:

>       This particular virus even has aliases that include "Hawaii,"
>"Marijuana," "New Zealand," "Smithsonian" or "Hamo."

C'mon, if we wait for the media to give us exact information... :-)

Regards,
Vesselin

------------------------------

Date:    19 Aug 91 09:14:44 +0000
>From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Hard disk locking ? (PC)

[e-mail] (Fridrik Skulason) writes:

>It was possible to trace the source of the infection, but now he wants
>some method to prevent anyone from working on his machine while he is
>away - for example by asking for a password on boot-up.

>This is easily solvable with additional hardware - some machines
>include this feature in the BIOS, but it is also possible to get an
>add-in card for this purpose.

Yes, as far as I know, the ThunderByte card offers password protection
among other anti-virus stuff.

>Software-only solutions are less secure of course, but they are
>sufficient in his case.  It is possible to create a small program
>which asks for a password when you boot from the hard disk, and cannot
>be bypassed simply by booting from a diskette.

It depends on what do you mean exactly by "cannot". A really skilled
penetrator won't be stopped by a software solution, no matter how
sophisticated. True, you may even encypt the whole disk with a
cryptographically strong algorithm (and of course not store the
password on the disk <g>). This will prevent him only from -reading-
the disk, not from writing on it.

>My questions:

>     #1 I guess that such a program already exists - but I have not yet
>        been able to find it.  Does anyone know of something like this ?

I have heard of a program, called PC-LOCK. It is shareware. I -can-
bypass it, therefore for me it's just garbage.

There is another thing, but it is commercial and is manifactured by a
Bulgarian firm. When you install it (as a device driver), you won't be
even able to boot from a diskette - the machine just hangs. Yeah, this
is achieved entirely in software... Nevertheless, it can be bypassed too.

>     #2 If the answer to #1 is "no", I'll probably write this, and might
>        make it available if anybody is interested.  The question is - are
>        programs like this a good idea ?  I can imagine some potential
>        problems, for example if the hard disk is "protected" in this way,
>        without the owner's permission, and if a utility to remove the
>        protection is included, it really makes the program rather useless.

My oppinion is that such programs are not a very good idea. As I already
said, all of them can be bypassed, if enough effort is applied. Also,
they sometins are in conflict with programs like Disk Manager, that
use the unused space of the first disk track...

Regards,
Vesselin

------------------------------

Date:    Mon, 19 Aug 91 10:32:00 +0100
>From:    [e-mail]
Subject: help identifying virus on PC (PC)

Hello,
      We have recently discovered a virus on some of our PC's here and
would appreciate it if anybody out there can recognise it and describe
it for us.  It manifests itself rather blatantly by displaying a
colour graphic on the screen of what looks like the pictorial
representation of the Mandelbrot set of Fractal geometry fame. (if
that rings a bell with anyone). There is also some text on the top
left hand corner "Execute: mov ax feb0, interrupt 21 any key to
continue!". The hex address there may not be 100% accurate. Anyway, we
would appreciate any help. Thanks.
                                     Paul Rothwell.

------------------------------

Date:    19 Aug 91 09:35:59 +0000
>From:    [e-mail] (Vesselin Bontchev)
Subject: Re: NEW VIRUS? (PC)

[e-mail] writes:

>1.- SCAN detects the virus in memory, then it sends and alert, saying that some
>thing strange is happening in the computer's memory, and migth want to turn it
>off.

Does SCAN identify the virus? (Does it print a name?)

>2.- A bozo message appears on the screen saying: "I'm killing the &%$,@... poli
>ce program ..."

After you have started SCAN? And do you use VSHIELD?

>5.- You discover that all your files, including those on the sub-directories, h
>as been converted to a 144 byte file that contains the message "Fakkir has %$,&
>@ this Go-Go file... Ha, Ha, Ha"

Is there something more that this message in the files? For such a primitive
virus 144 bytes seem sufficient... Are all these 144-byte files equal?

>I was searching for signatures, boot sectors, or any other clue for try to figu
>re-out how the virus works, but the attack was very faster, and lethal.

Was the boot sector destroyed too? If not, does it seem infected? Are there
any clusters, marked as bad on the disk?

Regards,
Vesselin

------------------------------

Date:    19 Aug 91 09:28:05 +0000
>From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Problem cleaning "LIBERTY" virus? (PC)

[e-mail] (Johnwee Lee) writes:

>  Recently, I was also given a disk from a friend that was infected
>with the LIBERTY virus. I am also having the same problem trying to
>remove it....  If anyone has any idea of cleaning or removing it
>without replacing the infected files please kindly let me know.

CLEAN is not able to disinfect most of the viruses that SCAN detects.
It just destroys the infected files. It is written in the documentation,
please read it. There is also a list of the viruses that CLEAN -is- able
to disinfect successfully. They are not very much - in fact only the most
often encountered viruses can be removed. McAfee's oppinion is that it is
safer to replace the infected files from non-infected backups or from the
original diskettes. I agree with him - very often it is impossible to
restore an infected file -exactly- in its previous state.

BTW, note that there are at least two variants of the Liberty virus.
You can also try F-Prot and Dr. Solomon's Anti-Virus Toolkit as
disinfection programs - they are quite good.

Regards,
Vesselin

------------------------------

Date:    19 Aug 91 09:43:28 +0000
>From:    [e-mail] (Vesselin Bontchev)
Subject: Re: More about the mutation engine (PC)

[e-mail] (Fridrik Skulason) writes:

>Normally I would ask Vesselin Bontchev for a translation, as the text
>is probably in Bulgarian, but I have not been able to reach him.  So,
>if there is anybody reading this who...

Well, this is probably a misunderstanding, but didn't my mail reach you?
I translated them on the same day I received your message. If you still
don't have them, do you want the translation posted here?

>       ... can display the Cyrillic character set on his/her PC.
>and
>       ... understands Bulgarian

Oh, the first thing is easy... :-) I have a small TSR program, that is
both a screen (EGA/VGA only) and a keyboard driver for Cyrillics... If
a lot of anti-virus researchers need it, I can send it to Ken.

About the second thing, well I guess that our language is not easier then
the Icelandic one... :-)

Regards,
Vesselin

------------------------------

Date:    Mon, 19 Aug 91 11:59:56 +0000
>From:    [e-mail] (Stephen R. van den Berg)
Subject: Re: Hard disk locking ? (PC)

Frisk wrote:
>One person here at the University of Iceland had the misfortune of
>having his hard disk trashed by the Spanish Telecom virus recently.
>It was possible to trace the source of the infection, but now he wants
>some method to prevent anyone from working on his machine while he is
>away - for example by asking for a password on boot-up.

>     #1 I guess that such a program already exists - but I have not yet
>        been able to find it.  Does anyone know of something like this ?

It does exist, it's called PC-Lock, can't remember who distributes it
right now.  I never used it, a friend of mine used it in his office.
I think it is ShareWare.  If you need more info, drop me a note, I'll try
to find it and will tell you where to buy/ftp it.

>     #2 If the answer to #1 is "no", I'll probably write this, and might
>        make it available if anybody is interested.  The question is - are
>        programs like this a good idea ?  I can imagine some potential
>        problems, for example if the hard disk is "protected" in this way,
>        without the owner's permission, and if a utility to remove the
>        protection is included, it really makes the program rather useless.

PC-Lock replaces your harddisk partition table, i.e. without typing
in your password, you can not access any harddrives by using DOS; not
even when booting by floppy.  As far as I can remember they do not supply
a lockbreaker program (no doubt someone wrote something like that), however
any direct disk editor like NDD or DE can probably be used to remove the
lock.  But in order to do this, some expertise is still needed.
- --
Sincerely,                                [e-mail]
           Stephen R. van den Berg (AKA BuGless).    [e-mail]

"Good moaning!"

------------------------------

Date:    Mon, 19 Aug 91 12:55:45 +0000
>From:    [e-mail] (Helmut Dier)
Subject: Re: HELP - possible virus (IBM 5150?)

You should clean yor disk, because the Jerusalem sort is a really
dumb one. It infects files on and on so it's no wonder they need a
longer time to load. you should be able to use CLEAN from McAfee
(I hope I spelled it correctly) to clean most files.
We had a lot of infections here at the university all over the last
year and we could "heal" most of the files using CLEAN.
Try to get it at some BBS (probably TRICKLE is the easiest to use).

Helmut (E-Mail: [e-mail])

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 144]
******************************************
VIRUS-L Digest   Wednesday, 21 Aug 1991    Volume 4 : Issue 145

Today's Topics:

VIRx on a 3COM network (PC)
System Layers and Hiding Places
Re: When can a virus infect (AMIGA)
Hard disk locking software (PC)
Where can I find VSUM9108.zip o .txt?
Re: Double quote char appear all over - virus? (PC)
Re: Hard disk password protection (PC)
Liberty virus (PC)
Re: Hard disk locking PC SECURITY (PC)
Scan (PC)
New Virus ? (PC)
Questions regarding Novell, Viruses & policy
Partition table virus on Toshiba 1200XE (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Mon, 19 Aug 91 16:56:37 +0000
>From:    [e-mail] (Albert Crosby,AG ENG 210,4452,5014447866)
Subject: VIRx on a 3COM network (PC)

I just tried using the VIRx scanning program on network volumes attahed
via 3Com 3+Open.  The scanner reported "Bad status reading partition table"
and stopped for a key press.  The program then presented a message that it
was "Scanning: \\              \DOSAPPS\" and paused.
         ^^^^^^^^^^^^^^ <= this space was filled with high order
                   garbage characters.

The command I had issued was:  VIRX D:\

D: is actually \\AGHELAB\DOSAPPS.  The scanner was apparently able to obtain
the last part of the name correctly.  VIRx then reported that it had scanned
0 files and 0 subdirectories.  If I scan a floppy, it works correctly, and if
I scan a directory on D: other than root it appears to work correctly.

The version of VIRx I tried was "Current as of 07/01/91", version 1.6.  SCAN
(McAfee Assoc.) reports that there are 46 directories and 1468 files on the
drive.

Has anyone else encountered problems like this?  Or have any pointers for
correcting it?  (SCAN also reported the drive free of viruses, BTW)

Albert

------------------------------

Date:    Mon, 19 Aug 91 12:22:32 -0700
>From:    [e-mail] (Rob Slade)
Subject: System Layers and Hiding Places



This week's column has been slightly delayed due to the marriage, this
weekend, of the columnist's daughter.

FUNGEN4.CVP   910819

                     Hiding in System Layers

One additional use that viral programs can make of operating
systems is as a source of hiding places.

Anyone who has ever tried to manage accounts on mainframes or
local area networks will recognize that there is a constant
battle between the aspects of security and "user friendliness" in
computer use.  This tension arises from the definition of the two
functions: if a computer is easy to use, it is easy to misuse.
If a password is hard to guess, it is hard to remember.  If
access to information is simple for the owner, it is simple for
the "cracker".

(This axiom often gives rise to two false "corollares".  First,
the reverse; that those systems which are difficult to use must
therefore be more secure; does not hold.  Secondly, many assume
that restricting the availability of information about a system
will make that system secure.  While this strategy will work in
the short term, its effectiveness as protection is limited.
Indeed, it often has the unfortunate side effect of restricting
information to those who should have it, such as systems
managers, while slowing the "attackers" only marginally.)

"User friendly" programs and operating systems tend to hide
information from the user.  There are two reasons for this.  In
order to reduce "clutter", and the amount of information that a
user needs to operate a given system, it is necessary to remove
options, and therefore, to a certain extent, functionality.  A
user friendly system is also more complex in terms of it's own
programming.  In order for the computer to behave "intuitively",
it must be able to provide for the many "counter-intuitive" ways
that people work.  Therefore the most basic levels of a graphical
user interface system tend to be more complex than the
corresponding levels of a command line interface system, and are
hidden from the user by additional intervening layers (which also
tend to add more  complexity.)

The additional layers in an operating system, and the fact that
a great deal of management takes place automatically, without the
user's awareness, is an ideal situation for a viral program.
Since many legitimate and necessary operations and changes are
performed without the user being aware of it, viral operations
can also proceed at a level completely hidden from the user.
Also, because the user is basically unaware of the structure and
operations of the computer, changes to that structure and
operation are difficult to detect.

copyright Robert M. Slade, 1991   FUNGEN4.CVP   910819


=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Mon, 19 Aug 91 20:29:37 +0000
>From:    [e-mail] (Ethan R Dicks)
Subject: Re: When can a virus infect (AMIGA)

[e-mail] (Kevin Kadow) writes:
>With ZEROVIRUS running, after booting from a TC500 hard drive, I ran
>across a newly acquired disk which, upon being inserted, resulted in:
>
>ZeroVirus gave a warning "ColdCapture has been changed!"

>I was
>under the impression that a boot-block virus could only start-up if
>you booted from an infected disk, not by simple insertion?

On the Amiga, there are two types of viruses: boot-block and
executable.  Boot Block viruses are only loaded into RAM when an
infected disk is booted.  Executable viruses are loaded into RAM
whenever an infected file is run.  I suspect that your infected disk
was a system disk, with the program :l/disk-validator on it.  Under
AmigaDOS 1.3 and lower, the system will load and run the disk
validator LOCATED ON THE DISK INSERTED if one is present and the bit
in the root block is set which indicated that the bit-map is invalid
and needs to be rebuilt.  If the disk-validator program is infected
and the disk is in need of validation, AmigaDOS will cheerfully run
the validator WITHOUT ASKING.  Under AmigaDOS 2.0, l:disk-validator is
run (from the system disk), not :l/disk-validator (from the inserted
disk), eliminating this security hole.  BTW, write protecting a disk
with an invalid bit-map prevents the system from updating the bit-map
and will cause the system to be infected all over again when the disk
is inserted.

- -ethan

- --
Ethan R. Dicks       | ######  This signifies that the poster is a member in
Software Results Corp|   ##    good sitting of Inertia House: Bodies at rest.
940 Freeway Drive N. |   ##
Columbus OH    43229 | ######  "You get it, you're closer."

------------------------------

Date:    Mon, 19 Aug 91 14:15:54 -0700
>From:    Steve Clancy <[e-mail]>
Subject: Hard disk locking software (PC)

In Virus-L 4-142  Fridirk Skulason writes:

>Software-only solutions are less secure of course, but they are
>sufficient in his case.  It is possible to create a small program
>which asks for a password when you boot from the hard disk, and cannot
>be bypassed simply by booting from a diskette.
>
>My questions:
>
>     #1 I guess that such a program already exists - but I have not yet
>        been able to find it.  Does anyone know of something like this ?

I have had a program called PC-Lock 1.1 for several years on our BBS.
According to the documentation, it does what you are asking.  The docs
say:

                    THE PC-Lock HARD DISK PROTECTION SYSTEM
                                 Version 1.1
                            (c) Copyright 1986 by

                           Johnson Computer Systems
                              20 Dinwiddie Place
                            Newport News, VA 23602

      WHAT PC-Lock DOES

      After you install PC-Lock you will be asked to enter your password
      each time you boot your computer from your hard disk. Just type
      your password and press return. The boot process will continue
      normally.  If you make an error, just re-type it correctly and
      press return.  When you boot from a diskette the system will boot
      normally, but you will not be able to access your hard disk.

I have not had personal exeprience in using it, so I don't really know
of any weaknesses it might have.  There may even be a more current
version.  However, I would be happy to UUENCODE the ZIP file and mail
it to you.

- -- Steve Clancy

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
%   Steve Clancy, Biomedical Library  %  WELLSPRING RBBS              %
%   University of California, Irvine  %  714-856-7996 300-2400 24hrs  %
%   P.O. Box 19556                    %  714-856-5087 300-9600 24hrs  %
%   Irvine, CA  92713   U.S.A.        %  [e-mail]          %
%                                     %  [e-mail]             %
%.....................................................................%
%       "As long as I'm alive, I figure I'm making a profit."         %
%                                           -- John Leas, 1973        %
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

------------------------------

Date:    Mon, 19 Aug 91 15:01:40 -0600
>From:    [e-mail] (JESUS BARRERA RAMOS)
Subject: Where can I find VSUM9108.zip o .txt?

Hi all!!!

I've been lookin' for VSUM9108.zip o .txt de Patricia M. Hoffman 'n I've
not found it...could some body tell me where can I get a copy of that
document?...I'd thank ya a lot...oh!...by the way...I've also been
lookin' for a program that convert executable code to source code I know
there're programs to do that but I've not found one...If somebody has
one...please send me a copy (if it's shareware) or tell me where can I
get one...thank ya in advance...bye.

                friendly
              Jesus Barrera Ramos
                (Eqix)

P.S. May be (and I'm almost sure) no body know me, I've been a member
of this list since last january but I'm quite a novice'n I've not sent
a lot of sugestions...anyway..I'm interested a lot on virus.

------------------------------

Date:    20 Aug 91 09:36:43 +0000
>From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Double quote char appear all over - virus? (PC)

[e-mail] (Thomas Wong) writes:

>One of the 386s in our lab has been having a strange problem.  Double
>quote characters slowly appears all over the screen.  I've checked the
>computer with VirusScan (SCAN 7.6V80)(latest?)  and no virus was
>found. Has anyone seen this before? How can I tell if this is a new
>(yet to be discovered) virus? What to do?  What to do....

My best guess is that this is not a virus. Probaly your video controller
is malfunctioning. Try changing it and see what happens.

Regards,
Vesselin

------------------------------

Date:    20 Aug 91 09:48:37 +0000
>From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Hard disk password protection (PC)

[e-mail] (Jon Freivald) writes:

>It requests a password on boot (installs via config.sys).  If the
>system is booted via floppy disk, the hard disk cannot be accessed
>without running a special utility on the PC-Vault diskette (unlike a
>couple other programs where you just plain can't access the hard disk
>period!).

As I wrote in one of my previous postings, it depends on what do you
understand by "cannot". You probably mean that when DOS boots, it
cannot recognize the disk (says "invalid disk drive" when you try to
switch to that disk). This, of course, does not mean that the disk is
not accessible to BIOS (using INT 13h, not INT 25h/26h). More exactly,
this means that any boot sector virus that is able to infect MBRs
(Master Boot Records - where the partition table resides), will be
able to infect a disk "protected" in this way.

Such protection schemes usually install themselves in the MBR, then
either encrypt the partition table, or move the original MBR to
another place. If a virus attacks such disk, it will just install
itself in the MBR and move the MBR, containing the protection program
to another place. When the computer is booted, the virus receives
control, stays resident in memory, then reads the moved MBR and
transfers control to it. Since the protection program resides there,
it will just ask for the password and so on.

Since all MBR infectors use BIOS to access the disk, there is no
possibility to "hide" the disk from them. It is possible, however, to
disinfect the disk automatically on reboot, but this is another story.

Regards,
Vesselin

------------------------------

Date:    Tue, 20 Aug 91 14:53:23 -0400
>From:    [e-mail]
Subject: Liberty virus (PC)

The Liberty virus showed up here in Boston last week at my employer's
Novell network. (My employer is NOT Northeastern University.) The
infection wasn't very bad and we cleaned it up quickly.

I note that there have been several mentions on the net lately that
people have gotten this virus and been unable to remove it with CLEAN,
and were forced to delete the files. We also experienced this problem.
I have mailed a copy to McAffee today for their examination, at the
request of their tech support department. Hopefully this will be
resolved in a future version of CLEAN.

Incidentally, is there a site from which I can FTP the latest version
of Flu Shot? I have an old (very old) copy on a floppy somewhere, but
I'd much rather have the newest version. (Please answer that by
private mail, no need to waste bandwidth.)
            Tom Farrell


------------------------------

Date:    Tue, 20 Aug 91 19:08:18 +0000
>From:    [e-mail] (Kevin Kadow)
Subject: Re: Hard disk locking PC SECURITY (PC)

Most of the small-round-key PC locks can be opened by using a fired
.22 shell like a key (to turn the peg in the lock).

DO NOT trust the keyboard lock to keep people from "playing" with your
machine.

  The only foolproof protection would be to disassemble the machine
and install a REAL lock in place of the factory-installed keyboard
lock, get a TSR that can lock the MOUSE when the keyboard is locked,
and lastly install a lock such that the case cannot be opened without
the appropriate key.

- --

[e-mail]                           kadokev@iitvax (bitnet)
                         My Employer Disagrees.

------------------------------

Date:    Tue, 20 Aug 91 16:29:02 -0600
>From:    Jesus Miguel Garcia <[e-mail]>
Subject: Scan (PC)

Whats the new Scan antivirus of Mcaffe?  I heard about version 83....
Thanks for help...

Miguel Garcia Rdz.
Monterrey, N.L.
Mexico

------------------------------

Date:    Tue, 20 Aug 91 21:05:00 -0400
>From:    [e-mail]
Subject: New Virus ? (PC)

I am having a problem running a program that requires 541K of free
conventional memory (according to the manual).  I get the message
"Program too big to fit in memory", even though I have about 552k of
free conventional memory (according to CHKDSK and some other programs
too).  The peculiar thing is that the program was running a few days
back, under this same configuration.  No change has been made to the
CONFIG.SYS or the AUTOEXEC.BAT files.  There are no TSR's in the
memory other than SHARE (even if there were, the largest free memory
block is larger than required).  The program does run if I get about
580K free.

I have checked the program for infection using F-PROT V1.16, and using
Norton Anti-Virus V2.00.  In both cases the results were negative.
Could this program be infected with a new virus?
Any comments?

Is there any place I could upload this program to have it checked
(can E-Mail be used for sending binary files) ?

Harpreet Singh
[e-mail]

------------------------------

Date:    Wed, 21 Aug 91 02:19:56 +0000
>From:    [e-mail] (Cumberland Newspapers)
Subject: Questions regarding Novell, Viruses & policy

    We have a novell network running v3.11 and have (touch wood)
    largely been unaffected by virus attack.

    We thus far have only PC compatibles on our net but soon will
    be adding some macs.

    We are looking to create and adopt a policy to prevent virus
    infection but it is not practical to prevent users bringing in
    floppies or prevent some users from using BBS's. If anyone has
    ANY suggestions I am open to them.

    and a few other questions....

    1)    Do there exist viruses that can infect novell fileservers ?
        (I don't mean .EXEs or .COMs or whatever on the server but
         the files that it runs like .NLMs etc )

    2)    Is there a way of putting a task on the server that scans for
        viruses when users try to conect ?

    3)    Is there some way I can keep the viruses off the executables
        on the server ?
                        many thanks
                        iain.
- --
Cumberland Newspapers (Software Development)          [e-mail]

Iain Holmes.    Ph: [phone] (B)  [phone] (H) Fax: [phone]
Craig Mitchel.  Ph: [phone] (B)

------------------------------

Date:    Wed, 21 Aug 91 10:55:26 +0000
>From:    Leila Burrell-Davis <[e-mail]>
Subject: Partition table virus on Toshiba 1200XE (PC)

We have a Toshiba 1200XE which has been diagnosed as having the
Telephonica Virus in the partition table of the 20MB hard disk. I've
tried repartitioning and reformatting the disk, but it is still
infected. I asked our local Toshiba dealer how to low level reformat
the disk and he said it was an IDE disk and it could only be done with
a special program which dealers have and can't resell. They'll quite
happily do it for us, but it's an hour's drive so I thought I would
enquire here first if there is any alternative solution.

Thanks

Leila
- --
Leila Burrell-Davis, Computing Service, University of Sussex, Brighton, UK
Tel:   [phone]              Fax:   [phone]
Email: [e-mail]  (JANET: [e-mail])

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 145]
******************************************
VIRUS-L Digest   Thursday, 22 Aug 1991    Volume 4 : Issue 146

Today's Topics:

RE: where is VSUM9108.ZIP or TXT
Re: Hard disk locking ? (PC)
Can virus infect PC data diskettes? (PC)
Re: Problem cleaning "LIBERTY" virus? (PC)
Re: Scan (PC)
Re: help identifying virus on PC (PC)
Re: Hard disk locking ? (PC)
Questions regarding Novell, Virus..
Bad hit on KENNEDY/12 Tricks Trojan?? (PC)
VIRx on a 3COM network (PC)
re: Partition Table Virus (PC)
Review of DISKSECURE (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Wed, 21 Aug 91 15:12:13 -0600
>From:    Diskmuncher <[e-mail]>
Subject: RE: where is VSUM9108.ZIP or TXT

>From:    [e-mail] (JESUS BARRERA RAMOS)

>I've been lookin' for VSUM9108.zip o .txt de Patricia M. Hoffman 'n I've
>not found it...could some body tell me where can I get a copy of that
>document?...I'd thank ya a lot

You won't find it...at least not under the old name.  Look for VSUMX9107.ZIP
on risc.ua.edu in the pub/ibm-antivirus directory.  Included below is some
information from one of the read-me files in the new package.
============================================================================
                      HyperText VSUM X9107 READ_ME.1ST

     With the June, 1991 release, the Virus Information Summary List
has been converted from its original ASCII list format into a custom,
hypertext database format.  With the new format, the product name has
been changed to HyperText VSUM.  The previous ASCII list product has
been discontinued, and will no longer be updated.

     Why the change to a hypertext database?  The original ASCII format
had become extremely large and unwieldy, it was difficult for most
people to effectively use.  Printing also had become a problem unless one
had a very high speed laser printer.  More importantly, the information
presented in the ASCII version was never really intended to be read
sequentially as a book, but instead to be a reference book or
encyclopedia.
=============================================================================

>...oh!...by the way...I've also been
>lookin' for a program that convert executable code to source code I know
>there're programs to do that but I've not found one...If somebody has
>one...please send me a copy (if it's shareware) or tell me where can I
>get one...thank ya in advance...bye.

    There are lots of these in the mirrors/msdos/disasm directory at
wuarchive.wustl.edu (PD1:<MSDOS.DISASM> on SIMTEL-20).  My favorite(s) are
    ASMGEN3.ZIP
    MD86.ZIP
    DIS86.ZIP

Note: these are disassemblers so you must know/understand Assembly Language.
To my knowledge, there are no reliable programs to reverse engineer programs
back to their original high-level source code (C, Pascal).
                John-David Childs
                Consultant, University of Montana
                [e-mail]

------------------------------

Date:    Thu, 22 Aug 91 12:29:00 +1200
>From:    "Mark Aitchison" <[e-mail]>
Subject: Re: Hard disk locking ? (PC)

[e-mail] (Vesselin Bontchev) writes:
> It depends on what do you mean exactly by "cannot". A really skilled
> penetrator won't be stopped by a software solution, no matter how
> sophisticated. True, you may even encypt the whole disk with a
> cryptographically strong algorithm (and of course not store the
> password on the disk <g>). This will prevent him only from -reading-
> the disk, not from writing on it.
>
> My opinion is that such programs are not a very good idea. As I already
> said, all of them can be bypassed, if enough effort is applied.

You can't have a 100% secure system, it is always a trade-off between
security and what you can afford - in time/inconvenience/money/spare
slots/RAM/etc. Just like fire-walls for protection, you assume that
after some time they will give up or you will return and see them.
Think of hardware protection systems in a computer - you could lift
the lid and unplug the card, or whatever. If you put a padlock on it,
a determined hacker will bring cutters! if you encrypt the data, it is
a matter of time before any code can be broken. But, of course, you
can feel happy if it takes, on average, over 20 years on the fastest
computer to crack the code, or to cut the padlock the person has to
think of bringing bolt cutters in advance, and must sneak them past
everyone in the office, etc.

To stop careless use of a computer, software is often enough. To stop
a virus from infecting a hard disk, a simple switch in the disk cable,
accessible by anyone, isn't a security risk, it is perfectly good for
the job. Not that either method is totally safe against every
eventuality, but good enough under the circumstances.

>Also,
> they sometins are in conflict with programs like Disk Manager, that
> use the unused space of the first disk track...
>
>Such programs need not use the unused space on the first track, the MBR is
>plenty big enough for password protection.

By the way, a copy of a lock program (not the PC-Lock others have
mentioned) is available via anonymous ftp from newton.canterbury.ac.nz
[132.181.40.1] in the directory: /pub/antivirus.  It is a FREEWARE
demo: you may use it for free, but not sell it, and should use it with
care (caveat emptor and all that). To use the program type in LOCK/?
and it will explain the rest. Please send comments back to me, and
I'll pass them onto the author. NOTE that the newton computer is small
and slow; it would be nice if some other ftp site made the program
available.

Mark Aitchison, Physics, University of Canterbury, New Zealand.

------------------------------

Date:    22 Aug 91 03:54:06 +0000
>From:    [e-mail] (Steve Masticola)
Subject: Can virus infect PC data diskettes? (PC)

A friend (who works on a network which was hit recently by the STONED
virus) asked me to post the following questions.

1. Can a virus infect data diskettes and propagate from them (possibly
by rewriting the boot track)?

2. Can viruses infect data files (not executables) downloaded from
BBSes?

Also, if someone has a pointer to an archive with info about PC
viruses (in plain text), or good magazine articles, I'd appreciate
knowing that, too.

Thanks,
- - Steve Masticola ([e-mail]).

------------------------------

Date:    Thu, 22 Aug 91 03:53:42 +0000
>From:    [e-mail] (McAfee Associates)
Subject: Re: Problem cleaning "LIBERTY" virus? (PC)

[e-mail] (Vesselin Bontchev) writes:
[some of message deleted]
>CLEAN is not able to disinfect most of the viruses that SCAN detects.

CLEAN-UP removes over 90% of reported viruses (i.e., viruses that are
in the "public").

>It just destroys the infected files.

If CLEAN-UP comes across a virus that it can not successfully remove,
than it prompts the user if it should overwrite and delete the file.

>It is written in the documentation,
>please read it. There is also a list of the viruses that CLEAN -is- able
>to disinfect successfully. They are not very much - in fact only the most
>often encountered viruses can be removed. McAfee's oppinion is that it is
>safer to replace the infected files from non-infected backups or from the
>original diskettes. I agree with him - very often it is impossible to
>restore an infected file -exactly- in its previous state.
[rest of message deleted]

Given the nature of the problem with the virus, I am more inclined to
believe that the problem is a result of a variant of the virus.
However, given the fact that no infected executables are available, we
(McAfee Associates) will have to wait until another infection of a
similar nature is reported.

Regards,

Aryeh Goretsky
McAfee Associates Technical Support
- --
McAfee Associates     | Voice [phone]    | [e-mail]  (business)
4423 Cheeney Street     | FAX   [phone]    | [e-mail](personal)
Santa Clara, California     | BBS   [phone]    |
95054-0253  USA         | v.32  [phone]    | CompuServe ID: 76702,1714
ViruScan/CleanUp/VShield | HST   [phone] | or GO VIRUSFORUM

------------------------------

Date:    Thu, 22 Aug 91 04:05:11 +0000
>From:    [e-mail] (McAfee Associates)
Subject: Re: Scan (PC)

[e-mail] (Jesus Miguel Garcia) writes:
>Whats the new Scan antivirus of Mcaffe?  I heard about version 83....

The current version of VIRUSCAN is V80.  The next release is scheduled
for the last week of August.  Or to be more accurate, is scheduled for
no sooner than the last week of August.

Aryeh Goretsky
McAfee Associates Technical Support

>Thanks for help...
>
>Miguel Garcia Rdz.
>Monterrey, N.L.
>Mexico

- --
McAfee Associates     | Voice [phone]    | [e-mail]  (business)
4423 Cheeney Street     | FAX   [phone]    | [e-mail](personal)
Santa Clara, California     | BBS   [phone]    |
95054-0253  USA         | v.32  [phone]    | CompuServe ID: 76702,1714
ViruScan/CleanUp/VShield | HST   [phone] | or GO VIRUSFORUM

------------------------------

Date:    Thu, 22 Aug 91 09:55:17 +0300
>From:    Tapio Keih{nen <[e-mail]>
Subject: Re: help identifying virus on PC (PC)

>it for us.  It manifests itself rather blatantly by displaying a
>colour graphic on the screen of what looks like the pictorial
>representation of the Mandelbrot set of Fractal geometry fame. (if
>that rings a bell with anyone). There is also some text on the top
>left hand corner "Execute: mov ax feb0, interrupt 21 any key to
>continue!". The hex address there may not be 100% accurate. Anyway, we
>would appreciate any help. Thanks.

The virus is Tequila virus. It is originated in Swizerland and its
authors are known (brothers, aged 18 and 21).
When infected file is executed for the first time, it'll check if hard
disk's partition table is already infected. If the virus notices that
there's no copy of it in partition table, it will infect it. Next time
when you boot your computer from the infected hard disk, the virus
will begin to infect files. It uses variable encryption on files, but
on partition table it is in decrypted form. Virus infects only .EXE
files and they grow by 2468 bytes. Depending on date and how many
times infected files have been executed, the virus will display that
mandelbrot picture. If one executes that program virus suggest to
execute, a text about L.I.N.D.A. and beer will be displayed.

Tapio

- --
Tapio Keih{nen  |  [e-mail]  |  DIO COMES - ARE YOU READY TO ROCK?
Disclaimer: This posting has nothing to do with nic.funet.fi archive server.

------------------------------

Date:    Wed, 21 Aug 91 23:31:53 +0000
>From:    [e-mail] (skiman)
Subject: Re: Hard disk locking ? (PC)

>[e-mail] (Fridrik Skulason) writes:
> One person here at the University of Iceland had the misfortune of
> having his hard disk trashed by the Spanish Telecom virus recently.
> It was possible to trace the source of the infection, but now he wants
> some method to prevent anyone from working on his machine while he is
> away - for example by asking for a password on boot-up.
>
> Hardware solutions...

How about a Bernoulli Box, or some other form of removable hard disk?
I know it's an expensive (and drastic?) solution, but if the data is
important ...

- --
Fraser Bryden
[e-mail]
"I seem to be having this tremendous problem with my lifestyle!"
Arthur Dent: Hitch Hiker's Guide to the Galaxy

------------------------------

Date:    Thu, 22 Aug 91 13:05:24 -0400
>From:    Ed Maioriello <[e-mail]>
Subject: Questions regarding Novell, Virus..

We have found that the best way of dealing with Macintosh viruses on a
Novell network is to limit the write privileges of lab users on the
server, and to use the Disinfectant Init along with periodic
Disinfectant scans.  Giving the user minimal write privileges will
help restrict where a virus might take hold on the Server.  This also
prevents users from changing the server configuration.  I also
recommend revoking write privileges to the Desktop file as well.

I have not found Mac viruses that infect DOS or Netware files, so the
worst case scenario is substantially reduced.  And while Mac viruses
seem to be more common they are usually less virulent than DOS
viruses.

Disinfectant from Northwestern U. has proven to be by far the most
effective virus eradication program.

In summary, rather that trying to erect huge anti-virus barriers which
are generally less than completely effective and tend to give a false
sense of security we remove the virus if and when they appear.

In nine months of supervising public Netware Macintosh Labs I have
often removed a virus from a user's disk, but never found one on a
server.

I hope this helps.

Ed Maioriello                                Bitnet:    EMAIORIE @ UGA
University Computing & Networking Servs.     Internet:  [e-mail]
University of Georgia
Athens, Ga. 30602                            (404)-542-5162
                    Where are the Snowdens of yesteryear?

------------------------------

Date:    Thu, 22 Aug 91 16:24:59 +0000
>From:    [e-mail] (Eric N. Lipscomb)
Subject: Bad hit on KENNEDY/12 Tricks Trojan?? (PC)

OK.  Here's a good one. . .

For whatever reason, one of our Business Profs decided to scan the
copy of VIRUCIDE on his hard disk, and lo and behold, SCAN 5.3C67
finds Kennedy and 12 Tricks Trojan in VIRUCIDE.EXE.  VIRUCIDE,
scanning itself, finds nothing.  SCAN also tells us that the file is
compressed with LZEXE and is infected internally.  Hmmmm.

Next step, we run SCAN 6.3V72 on VIRUCIDE.EXE, and the Kennedy virus
reveals itself again, but not the 12 Tricks Trojan.  Hmmm.  Next step,
run the latest release of SCAN.  Bingo, it finds Kennedy.  All
versions of SCAN that we throw at it find Kennedy and tell us that the
file is LZEXE compressed.

Now, a bit of info about VIRUCIDE: the file is 40209 bytes long, dated
5-8-90.  It appears to the user to be functioning properly, and even
though SCAN says it's infected, nothing *apparently* happens to the
system as a result.  However, one of our techies is looking at the
execution of the program, and has found that as VIRUCIDE scans a file,
it also attempts to perform a write to side 0 track 0 sector 6, thus
far unsuccessfully.  One of the strings it attempted to write was
"Disk Killer".  Hmmmmm.

F-PROT being my anti-virus package of choice, I threw VIRUCIDE at the
mercy of that.  F-FCHK didn't find anything in VIRUCIDE.EXE, nor did
it give any indication that the file was compressed in any way.  Next,
I installed F-DRIVER.SYS (with all necessary files, etc.) and *ran*
VIRUCIDE.EXE, and F-DRIVER let it through.  Hmmmm.

Now, except for the suspicious attempts to write to the boot sector,
it seems to me that McAfee SCAN is giving a false positive on the
Kennedy virus in VIRUCIDE.  VIRUCIDE (another, later version that
scanned clean by everything we threw at it) and F-PROT don't identify
anything.  And an old version of SCAN identified the 12 Tricks Trojan.
Unfortunately, I don't have any other disk scanners laying around that
I can check it against.  But our techies are looking a little more
closely into this suspicious disk write behaviour exhibited by the
suspect VIRUCIDE.

Any thoughts/ideas from the list at lagre, specifically the McAfee
crew (since both SCAN and VIRUCIDE came from McAfee)?  This is
certainly something that our University will take into serious
consideration as talks finalize on which product to go with as a
campus standard.

Thanks for your time!

}lips
- --
Eric N. Lipscomb, Lab/Network Manager Academic Computing Services
Email:  [e-mail]        "Golf is something you do to make
        [e-mail]         the rest of your life look good."

------------------------------

Date:    Thu, 22 Aug 91 11:22:49
>From:    [e-mail]
Subject: VIRx on a 3COM network (PC)

>From:    [e-mail] (Albert Crosby,AG ENG 210,4452,5014447866)
>
>I just tried using the VIRx scanning program on network volumes attahed
>via 3Com 3+Open.  The scanner reported "Bad status reading partition table"
>and stopped for a key press.  The program then presented a message that it
>was "Scanning: \\              \DOSAPPS\" and paused.
>         ^^^^^^^^^^^^^^ <= this space was filled with high order
                   garbage characters.

Yeah, that's a problem we found out about immediately after the last
release.  It'll be fixed up in the next release of the code (actually,
the release *after* the next release).

It stems from some weird interactions we noted on Novell networks,
doing a workaround to solve that problem and then discovering that
3COM does stuff just differently enough to cause the high order
garbage you found.  Mea culpa: I only have a small Novell network
here, and should have checked with a 3COM dude.

Please give a call to Microcom at 919-490-1277 and report this bug?
See, then collect the bugs, stick it on a sheet of paper, and then
badger me mercilessly until that sheet of paper is nothing but cross
outs.

Sorry for the hassle.

Ross
 Author, VIRx

------------------------------

Date:    Thu, 22 Aug 91 10:15:40 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: re: Partition Table Virus (PC)

Ms. (safe) Burke-Davis:

     I have never found it necessary to do a low level format of a drive
(including IDE) however have done it occasionally when there has not been any
information on the disk needing saving (all data is lost after a LLF). However
there is another method that a skilled technician can use.

    First, cold boot from a write-protected floppy disk containing DEBUG
and CHKDSK. Run CHKDSK (or SCAN /M) to determine if the virus is in memory -
if so the memory will show a loss of 1k from the TOM (640k machines normally
return 655360 bytes. 654336 or less is a danger sign unless something else is
going on (I do not know how your PC is configured so must be vague).

       If clean, my notes show that the virus moves the real Master Boot
Record (partition table) to track 0 head 0 sector 7. To disinfect, just
verify that track 0 head 0 sector 7 contains the MBR (look for the ASCII
warning messages near the end) and copy it to track 0 head 0 sector 1. This
will disconnect the virus code in sector 6 from the initialization sequence.
(to be really safe, zero out sector six).

    The PC should now be safe to use.

    This is a "stealth" virus so before disinfecting, you must make sure
that the virus is not resident in memory. Also, the TELEPHONICA infects
executable files so you must make sure that they are all cleaned before
execution or it will re-infect the PC. Just be careful but a low-level format
is unnecessary for a professional.

                    Hope this helps,

                            Padgett

------------------------------

Date:    Tue, 20 Aug 91 12:17:00 -0700
>From:    [e-mail] (Rob Slade)
Subject: Review of DISKSECURE (PC)

After a brief (ack ... two months!?!) hiatus, another review.  Pursuant
to the recent discussions regarding hard disk locking, that's basically
what DISKSECURE does.  And I'm *still* waiting for some smart company to
make a hard disk with a write protect switch ...

PCDSKSEC.RVW   910816
                        Comparison Review

Company and product:

A.  Padgett Peterson
POB 1203
Windermere, FLA, 34786, USA
[phone] eves Florida time
[phone] fax
DISKSECURE v .95

Summary:

Low level hard disk protecion to prevent access, by virus or
otherwise, to hard disk.

Cost      not yet released as shareware

Rating (1-4, 1 = poor, 4 = very good)
     "Friendliness"
          Installation   3
          Ease of use    3
          Help systems   3
     Compatibility       2
     Company
          Stability      2
          Support        3
     Documentation       2
     Hardware required   3
     Performance        3
     Availability
     Local Support

General Description:

DISKSEC.EXE replaces the partition table of the hard disk with
code which performs load time checking and prevents access to the
hard disk if booted from floppy, and offers software write
protection to the system areas of the disk.  CHKSEC.EXE verifies
DISKSEC operation, and FLOPSEC.EXE creates a bootable floppy for
maintenance purposes.

            Comparison of features and specifications



User Friendliness

Installation

Default installation is simple and can be accomplished through a
supplied batch file (DSINSTAL.BAT).  A "quick start" reference is
provided along with the regular documentation.  For protection of
the hard disk only DISKSEC is required to be run, although this
limits the possibilities for recovery.

Novice users may not be sufficiently aware of the dangers
inherent in this process.  The program is replacing the partition
table of the hard disk, and, if it fails, all information which
the computer requires to access the disk and information will be
lost, even if the information is not, physically, erased.
Although the possibility of this is very small, a backup of the
partition boot record prior to installation would be a good idea.

Ease of use

Operation of the programs is simpe.  DISKSEC provides ample
prompting and opportunity for the user to stop at any point.
CHKSEC and DSRPART are quite terse in the feedback that they
provide to the user, but operate easily and well.

Help systems

None provided.  DISKSEC is well prompted and the other programs
have no options.

Compatibility


Company Stability

Padgett is an unstable personality, and should be avoided when
driving "The Judge."

Company Support

Padgett is well known as a contributor to VIRUS-L/comp.virus.

Documentation

The documentation is quite clear to anyone familiar with MS-DOS
operations.  Occasionally certain points may not be clear to
novice users (for example, the fact that "removal" of DISKSECURE
is done via the DSRPART program.)  The spelling could use some
work.

Hardware Requirements

None specified, but a hard disk and at least one floppy disk
(which can be used to boot from) would appear to be minimum
requirements.

Performance

In testing, DISKSECURE detected the presence of the BRAIN virus
and prevented infection.  DISKSECURE detected the presence of the
Stoned virus.  Infection of the hard disk occurred and the disk
was not accessible thereafter, even after booting from a clean
floppy.  Running DSRPART.COM removed the infection.  (NB - access
to the hard disk is restored only after rebooting once
DSRPART.COM has been run.)

Creation of a "maintenance" diskette with FLOPSEC appears to
render the diskette unusable for other purposes.  Diskettes with
important files on them should not be used, and nothing should be
written to them thereafter.

It appears that the program indulges in some "stealth" technology
of its own: the partition boot record appears unchanged after
installation.

Local Support

None provided.

Support Requirements

DISKSECURE is simple enough for a novice user to run, and should
provide significant protection with minimal risk.  Recovery is
quick and easy, as long as the user remembers the importance of
DSRPART.COM.  Intermediate users should note the difficulties in
running system optimizing software.

copyright Robert M. Slade, 1991   PCDSKSEC.RVW   910816


=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 146]
******************************************
VIRUS-L Digest   Friday, 23 Aug 1991    Volume 4 : Issue 147

Today's Topics:

System Layers and Hiding Places
Questions regarding Novell, Viruses & policy
Types of virus
Ghosting
Hardware and software protection mechanisms
Re: Can virus infect PC data diskettes? (PC)
RE: Hard disk locking (PC)
Revised Product Test for VIRx - - Version 1.7
Computer Insecurity Terminology

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Thu, 22 Aug 91 15:15:29 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: System Layers and Hiding Places

  >From:    [e-mail] (Rob Slade)

  >                     Hiding in System Layers

  >if a computer is easy to use, it is easy to misuse.
  >If a password is hard to guess, it is hard to remember.  If
  >access to information is simple for the owner, it is simple for
  >the "cracker".

I think Rob had tongue in check  when posting this,  something that is
evident when the rest  of the piece is  read but can  creep up on  the
unsuspecting   easily.   That    these    axioms  are   archaic  is an
understatement even to an antediluvian  individual such as myself, but
to an undergraduate receiving  his/her/etc. first taste of   JCL, they
may seem proverbial.

Passwords are a  case in point: one  can be completely unguessable but
easy to remember  if  an  algorithm  is used  (something essential for
access to  a large number  of processors) and if  made  up  of  two or
three, one  of which is  numerical, can  be even  harder to crack. For
instance,  1991  might be the "Year  of  the Worm", the  month: August
(08),  and the particular system   "Plato". This month's password  for
"Plato" might be WOR08PLA  - an eight character  password that is easy
to remember yet nearly impossible to  crack.  Unique for every system,
and easy to change monthly.

  >The additional layers in an operating system, and the fact that
  >a great deal of management takes place automatically, without the
  >user's awareness, is an ideal situation for a viral program.
  >Since many legitimate and necessary operations and changes are
  >performed without the user being aware of it, viral operations
  >can also proceed at a level completely hidden from the user.
  >Also, because the user is basically unaware of the structure and
  >operations of the computer, changes to that structure and
  >operation are difficult to detect.

True, and many  viruses rely  on this  - however, this   relates to  a
"plain vanilla"  operating system.  Nothing says  that  you cannot add
integrity  management routines at any layer  other than no-one sems to
have done  so yet.  In the IBM   PC, it  is entirely  possible  to add
integrity management at the BIOS level and to maintain integrity up to
the user level. This can also be done transparantly to the user unless
an exception occurs.

The key is to simplify authorized actions  for authenticated users and
not just make others difficult, but make them impossible.

                                                         Padgett

------------------------------

Date:    Thu, 22 Aug 91 15:16:11 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: Questions regarding Novell, Viruses & policy

  >From:    [e-mail] (Cumberland Newspapers)

  >       1)      Do there exist viruses that can infect novell fileservers ?
  >               (I don't mean .EXEs or .COMs or whatever on the server but
  >                the files that it runs like .NLMs etc )

There has been a report of one that may do  this (GP1) but  I have not
seen it. The capability is feasible but would not be simple.

[Ed. The most recent report of the GP1 virus that I've seen is in the
August 1991 issue of Virus Bulletin.  On page 9, Eric Babcock (of
Novell Inc.) describes the virus in reasonable detail.  From his
description, it appears that GP1 does not circumvent Novell
file/directory protection per se; it merely watches the Novell
function calls for a specific form of login request which does not use
encrypted passwords and then broadcasts this information over a
network socket.  This looks (to me) to be entirely different, albeit
potentially harmful in itself, than a virus which can circumvent a
server's file access control and actually write to a file to which the
user has no write permission.]

  >       2)      Is there a way of putting a task on the server that scans for
  >               viruses when users try to conect ?

I recommend to Netware prople that the login  script contain "SCAN NUL
/M /CHKHI" and errorlevel branches if the client is found  infected to
be effective.* Combined with Scanning of outside floppies,  a checksum
integrity routine on the clients,  and  a periodic checksum validation
of server files from a known clean  system,  it would be difficult for
anything to get in.

          3)      Is there some way I can keep the viruses off the executables
                  on the server ?

Proper use   of  the rights   flags to    make  executables and  their
directories read only is a good start. Use  of a  scratch directory(s)
and copying flies from  read-only repositories  is effective for those
unruly applications that insist on being able  to write to themselves.
RAMdisks on the client are even better.

                                                         Padgett

* - At present I know of no virus scanner other than McAfee's that can
scan memory only for resident  viruses  (and he does not document it).
The CHKHI switch for high memory is a recent addition.

------------------------------

Date:    22 Aug 91 19:41:23 +0000
>From:    [e-mail]
Subject: Types of virus?

Hello I just wanted to ask u about three kinds of virus , how to
prevent them what are they and what does they do, all of these for my
homework, Thank you.

------------------------------

Date:    Thu, 22 Aug 91 18:32:40 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: Ghosting

    Recently several vendors have been taken to task for false
positives resulting from signature strings being found in memory that
match viruses.  Generally, this occurs in two cases: first following
the execution of another anti-viral product that has left its own
strings in memory, and second folowing execution of a program that one
had a virus but has been removed.

    Once the mechanisms involved are understood, readers should be
able to understand why this occurs, and why they should be grateful
that it does not happen more often:

    In the dark distant past (like 1990), Ghosting did not occur
since most anti-viral products did not bother to check memory at all &
were content just to analyze the files on disks. Those that did
usually confined themselves to the viruses that posed a danger to the
anti-virus product or which pactised "stealth" to hid their traces. In
those cases the only choice was to find them in memory since, when
resident, they either could not be found on the disk or would triger
their bomb on detection of anti-viral activity.

    Quickly though, vendors found it necessary to at least have
the capability to find ALL viruses in memory, not just the dangerous
ones and ghosting began. Since it was only an occational problem, and
usually involved other anti-viral products, not much was done about
it. Also, recent versions of some anti-viral software has been subject
to a much more disturbing phenomena, that of missing some active
infections, and makes vendors doubly cautios about any changes that
might trigger a "false negative" - declaring a PC clean when it is
infected.

    The major problem today is the method of scanning memory for
viruses.  Users are demanding ever faster operation while the increase
in viral numbers is having the opposite effect.

    Vendors face the problem that while most viruses are
relatively easy find in a program (commands are usually found at
specific offsets), in memory the viral signature could be anywhere
(well, almost anywhere) in memory. We are starting to see products
that are more specific about where they look but while some viruses
will only inhabit certain locations, others could be anywhere in RAM,
high or low.

    The major reason for this is that the vectors used to execute
a virus while generally an explicit JMP in a program, are often hidden
several layers down in memory and cannot be relied upon. Consequently,
when a virus hunter finds a match in memory, there is often no way to
tell if it is active or just a fragment and when in doubt, they MUST
report a positive.

    Now the reason ghosting is not more prevalent than it is is
because anti-viral products tend to be rather large (v80 of a popular
one occupies over 170k fully expanded) and the memory they use is
cleared by the load.

    Consequently, if two anti-viral programs are executed, for the
second to detect ghosting from the first, the second had to be smaller
than the first, or had to start from a lower memory location (an
interesting experiment I may try RSN).

    Logically, ghosting would be somewhat more likely if a scanner
was run while a non-encrypting TSR with expanded strings was already
resident.  Could provide some interesting effects.

    In any event, as the number of viruses (and signatures)
continue to increase and the avaialble signatures decrease, it would
not be surprising to see the tendancy for ghosting as a result of
using multiple products to increase.

    Meanwhile, we still have the second of the two causes of
ghosting to account for: the "disinfected" file.

    Here we have an oddity of DOS at work, the cluster. Consider a
2k .COM file that contracts the Jerusalem (1808 bytes) virus. Many
older machines with 32 Mb disks use a 4096 byte (4K) cluster size.
This is the minimum disk quanta that DOS can allocate so the original
file occupied 1 cluster (the minimum). Not surprisingly, the infected
file also occupied 1 cluster, just filling more of it.

    When the virus disinfectant came along, chances are that it
just removed the virus vector at the start of the program, replaced
the first few bytes with the ones from the original file that the
virus stored, and adjusted the file size. The virus is now
disconnected and the code following the program is just noise.

    However, unless the viral code is stripped off manually, it is
still there and when the program is executed next, the whole cluster
is mapped into memory and often into the disk buffer (though these
generally have a finer granularity). If the program was larger than
the scanner that runs next (obviously not in the example) or goes TSR,
guess what is liable to happen ?

    Again, the scanner cannot tell that the viral code is
disconnected since a signature check is often only 10-20 bytes, just
that it found a match & pop goes the weasel.

    Personally, I cannot fault a vendor that gives me an
occasional false positive since there are other tools to use in
determining whether it was real. It is the false negatives that worry
me.

                        Padgett

------------------------------

Date:    Fri, 23 Aug 91 01:02:00 +0000
>From:    William Hugh Murray <[e-mail]>
Subject: Hardware and software protection mechanisms

> My opinion is that such programs are not a very good idea. As I already
> said, all of them can be bypassed, if enough effort is applied.

In security, we call this Jakes' law.  The law says "Anything hit with a big
enough hammer will fall to pieces."  Anything built by man can be broken by
man.  The trick is to make the cost of the break exceed the value while
not spending more to avoid the loss than taking it would cost you.

That having been said, there is still a kernel of truth here.  That is,
hardware mechanisms may not be as vulnerable to software is as is other
software.  On the other hand, the strength of hardware mechanisms is
limited by the laws of physics, while software mechanisms can be made
arbitrarily strong.

William Hugh Murray

------------------------------

Date:    Fri, 23 Aug 91 12:56:00 +1200
>From:    "Mark Aitchison, U of Canty; Physics" <[e-mail]>
Subject: Re: Can virus infect PC data diskettes? (PC)

[e-mail] (Steve Masticola) writes:
> 1. Can a virus infect data diskettes and propagate from them (possibly
> by rewriting the boot track)?

Yes. The definition of a "data diskette" is simply one which won't
load DOS, but it will still try - then give a message to the effort
you should try another. This message, and code to try to load the
system, is on the boot sector which viruses attack. The virus infects
even if the operating system can't be loaded from that disk by the
original boot sector which is then called!

> 2. Can viruses infect data files (not executables) downloaded from
> BBSes?

Yes. Remember that "data files" in some case are executed, not many,
though.  Think of spreadsheets with complex calculations in the cells.
Few viruses, however, attack anything other than the boot sector and
.EXE & .COM files.

> Also, if someone has a pointer to an archive with info about PC
> viruses (in plain text), or good magazine articles, I'd appreciate
> knowing that, too.

There probably should be a FAQ for this newsgroup, however the closest
thing is a monthly posting that lists anonymous ftp sites where you
can get information.

Mark Aitchison, Physics, University of Canterbury, New Zealand.

------------------------------

Date:    Fri, 23 Aug 91 15:57:00 +0100
>From:    "Olivier M.J. Crepin-Leblond" <[e-mail]>
Subject: RE: Hard disk locking (PC)

   First of all, I seem to remember that the original question was
dealing with the use of a computer in an office by unauthorised users.
The PC was accidentally infected with Spanish Telecom as a result. A
great number of methods to lock the hard disk have then been
suggested, some being *VERY* expensive indeed.
   I believe that the use of the keyboard lock situated on virtually
any PC is a suitable deterrent. Remember that the office environment
is supposed to be a "friendly" environment. ie: NO HACKERS. If no
keyboard lock is available, then use the SETUP program to change the
hard disk number. Only viciously determined users will want to pass
the test of guessing the reason for an "Invalid Media Type" error.
   Now if one deals with hackers, then I must say that a PC is a very
insecure box. Why pay as much in additional hardware, customised
locks, locking of the case, clamping of the PC on the desk, and of the
desk on the floor, and adding an alarm system ? :-) Has anyone heard
of having a PC in a locked office ?  For classified data, I suggest
the use of a removable hard disk, or floppies, both of which are
stored away in a safe, or locked cupboard.
   These solutions, albeit less exotic than on-line passwords, are
much cheaper.

Olivier M.J. Crepin-Leblond, Research Student, Communications Systems,
   Electrical Engineering Dept., Imperial College, London, UK.

------------------------------

Date:    Fri, 16 Aug 91 15:24:37 -0600
>From:    Chris McDonald ASQNC-TWS-R-SO <[e-mail]>
Subject: Revised Product Test for VIRx - - Version 1.7

*******************************************************************************
                                                                          PT-41
                                       July 1991
                                 Revised August 1991
*******************************************************************************

1.  Product Description:  VIRx is a copyrighted program written by Ross M.
Greenberg to detect computer viruses and malicious programs.  VIRx is the
detection portion (VPCScan) of the commercial protection program VIREX-PC
(reference PT-23, revised May 1991).

2.  Product Acquisition:  The program is free.  Mr. Greenberg has made it
available on many bulletin boards and software repositories, to include the
MS-DOS repository on simtel20 [192.88.110.20].  The current path on simtel20 is
pd1:<msdos.trojan-pro>virx17.zip.

3.  Product Tester:  Chris Mc Donald, Computer Systems Analyst, Information
Systems Command, White Sands Missile Range, NM 88002-5506, DSN:  258-4176, DDN:
[e-mail] or [e-mail].

[Ed. The remainder of this product review is available by anonymous
FTP on cert.sei.cmu.edu in the pub/virus-l/docs/reviews directory.]

------------------------------

Date:    06 Aug 91 16:45:25 +0000
>From:    [e-mail] (Johnathan Vail)
Subject: Computer Insecurity Terminology

          Dictionary of Computer Insecurity

         Compiled by Johnathan Vail ([e-mail])


This list started out as a collection of a few computer virus related
terms that I wrote for discussion in comp.virus.  Several people have
contributed comments and suggestion to my original list.  Tom
Zmudzinski contributed an excellent list of computer security terms
that now form the bulk of this list.  At this time, I will serve as
the focus and maintainer of this list.  Please submit any comments and
additions to me.  My address is [e-mail].


HISTORY:

     6 Aug 1991 JV    - First release.

________________________________________________________________________


async interrupt (attack) - to exploit system vulnerabilities arising
    from deficiencies in the interrupt management facilities of an
    operating system.


back door - This is an undocumented feature added to a product which
    can allow those who know about it to gain access to features that are
    otherwise protected.  The original Tempest video game was supposed to
    have a key sequence that would allow the author of the firmware to get
    free games in an arcade.  Some military systems are rumored to have
    back doors in their software that prevents their being used against
    the countries that built them.


blivet (attack) - Unrestricted use of a limited resource (e.g., spool
    space on a multi-user system).  [Classically defined as "ten pounds of
    horsesh*t in a five pound bag".]


browsing - Gaining unauthorized read-only access to files.


C2 Catch-22  - Refers to the paradox that all federal computers are
    required to be certified to the C2 level of Trust (or better) by 1992
    (especially if they are to be permitted access to a network), yet
    because no C2 certification has ever been performed with the network
    software active, NSA will revoke the certification of any system as
    soon as it is connected to a network.  [Also "C2-by-'92 Catch-22".]


cascading - To gain additional privileges on a host (or within a
    process) by using those privileges legitimately (if perhaps unwisely)
    granted to casual users.


crayola books - A disparaging reference to the "rainbow books",
    commonly used when referring to the upcoming rewrite of NSA's
    technical computer security guidelines.


crypt (attack) - Stealing the system password file and looking for
    known encrypted passwords.


data diddling - To alter another's data (especially, to do so subtly
    so it will not be detected); a major breach of the hacker ethic.


dictionary (attack) - Trying a dictionary of commonly used or vendor
    installed passwords.


ethical hacker - Someone who espouses the view that he/she may
    "ethically" penetrate any computer or network so long as no data is
    altered.  [Colloquially among computer security professionals: a dead
    hacker (or one who has ceased hacking).]


hacker ethic - ["Data is free."]  The point of view that all
    information is (or at least, should be) freely available to anyone who
    wishes to read it.  When used ironically, it refers to the propensity
    of some less-than-ethical hackers to justify even the most blatant
    disregard for the rights of others by claiming that they did no harm.


leapfrog (attack) - Using userid and password information obtained
    illicitly from one host (e.g., downloading a file of account IDs and
    passwords, tapping TELNET, etc.) to compromise another host.  Also, to
    TELNET through one or more hosts in order to confuse a trace (standard
    hacker procedure).


magic cookie - This is a usually benign feature added to a product by
    the programmer without official knowledge or consent.  One example of
    the is the 'xyzzy' command in Data General's AOS operating system.
    Another is the "RESIST THE DRAFT" message in an unused sector of Apple
    Logo.


masquerading - To assume the identity of another user to gain
    unauthorized access to a host or network.


mockingbird - Software that intercepts communications (especially
    logon processes) between users and hosts and provides system-like
    responses to the users while obtaining information (especially account
    IDs and passwords).


pest - A set of instructions that self-replicates uncontrollably,
    eventually rendering a network or system unusable via a
    blivet attack.


phage - An autonomous program that inserts malicious code into
    other autonomous programs (e.g., a computer worm or probe
    that carries a virus or trojan horse program).


probe - A non-self-replicating, autonomous program (or set of
    programs) that has the ability to execute indirectly
    through a network or multi-partition computer system
    (e.g., various hacker utilities).


rainbow books - NSA's technical computer security guidelines.
    So named because each of the books is published with a
    different color cover.  [See "crayola books".]


scavenging - To exploit unerased residual data.


spoofing - To exploit the inability of a host's remote users to verify
    at any given time that they are actually communicating with the
    intended system or process.


stealth virus - This is a type of virus that attempts to hide its
    existence.  A common way of doing this on IBM PCs is for the virus to
    hook itself into the BIOS or DOS and trap sector reads and writes that
    might reveal its existence.


trapdoor - A method of bypassing a sequence of instructions, often
    some part of the security code (e.g. the computer logon).


time bomb - This is code or a program that checks the systems clock in
    order to trigger its active symptoms.  The popular legend of the time
    bomb is the programmer that installs one in his employer's computers
    to go off in case he is laid off or fired.


trojan (horse) - This is some (usually nasty) code that is added to,
    or in place of, a harmless program.  This could include many viruses
    but is usually reserved to describing code that does not replicate
    itself.


unknown system-state (attack) - To exploit the conditions that occur
    after a partial or total system crash (e.g., some files remain open
    without an end-of-file condition allowing an intruder to obtain
    unauthorized access to other files by reading beyond the real EOF when
    service is resumed).


virus - a piece of code that is executed as part of another program
    and can replicate itself in other programs.  The analogy to real
    viruses is pertinent ("a core of nucleic acid, having the ability to
    reproduce only inside a living cell").  Most viruses on PCs really are
    viruses.


worm - A self-replicating, autonomous program (or set of programs)
    that can replicate itself, usually over a network.  A worm is a
    complete program by itself unlike a virus which is part of another
    program.  Robert Morris's program, the Internet Worm, is an example of
    a worm although it has been mistakenly identified in the popular media
    as a virus.

________________________________________________________________________

"Always Mount a Scratch Monkey""
 _____
|     | Johnathan Vail | [e-mail]
|Tegra| [phone] | N1DXG@448.625-(WorldNet)
 -----  [e-mail] {...sun!sunne ..uunet}!tegra!vail

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 147]
******************************************
VIRUS-L Digest   Monday, 26 Aug 1991    Volume 4 : Issue 148

Today's Topics:

Re: Hard disk locking (PC)
Re: Hard disk locking ? (PC)
Can virus infect PC data diskettes? (PC)
Bad hit on KENNEDY/12 Tricks Trojan?? (PC)
RE: where is VSUM9108.ZIP or TXT
Re: Double quote char appear all over - virus? (PC)
Can a virus be LAGAL?!
Re: Bad hit on KENNEDY/12 Tricks Trojan?? (PC)
Re: Bad hit on KENNEDY/12 Tricks Trojan?? (PC)
4096 help needed (PC)
Re: Ghosting
The Wisconsin Virus???!!! (PC)
EICAR & CARO adresses needed
Virus Simulator available (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    23 Aug 91 13:29:00 -0500
>From:    "William Walker C60223 x4570" <[e-mail]>
Subject: Re: Hard disk locking (PC)

[e-mail] (Fridrik Skulason) writes:

>It was possible to trace the source of the infection, but now he wants
> some method to prevent anyone from working on his machine while he is
> away - for example by asking for a password on boot-up.

> This is easily solvable with additional hardware - some machines
> include this feature in the BIOS, but it is also possible to get an
> add-in card for this purpose.

JDR Microdevices now has a password security card which they call
"Gatekeeper."  This plugs into an 8-bit slot, prevents the machine from
booting without a valid password (even from floppy), and can have up to
15 passwords per card (could be useful for shared machines).  It does
not modify the partition table or any other part of the disk, and it
does not encrypt data.  I have no affiliation with JDR, and I have not
tested the card -- I'm merely mentioning its availability and advertised
functions.

> Software-only solutions are less secure of course, but they are
> sufficient in his case.  It is possible to create a small program
> which asks for a password when you boot from the hard disk, and cannot
> be bypassed simply by booting from a diskette.

Vesselin and several others are right in that software alone cannot
provide adequate security for a PC.  In fact, the National Computer
Security Center states that "... users should be wary of claims for
products (particularly software) which claim to provide 'absolute'
security"  (NCSC-WA-002-85, "Personal Computer Security
Considerations").  Because of how PCs are implemented, any software-only
security system cannot possibly guarantee a secure system.  I have
successfully bypassed software security schemes, including two
commercial packages which supposedly prevent access to the hard disk
when booted from a floppy.  I'm sure Vesselin, Padgett, and others have
done so as well.  Anyway, to make a long story short ("too late" :-) ),
it is NOT possible to write a program which cannot be bypassed by
booting from a diskette.

Bill Walker ( [e-mail] ) |
OAO Corporation                        |
Arnold Engineering Development Center  | "I'd like to solve the puzzle, Pat"
M.S. 120                               |
Arnold Air Force Base, TN  37389-9998  |

------------------------------

Date:    Fri, 23 Aug 91 10:08:38 -0700
>From:    [e-mail] (Rob Slade)
Subject: Re: Hard disk locking ? (PC)

I have long decried that fact that hard drive manufacturers still have
not thought to include a cheap and simple write protect switch on hard
drives.  (Yes, I do know that most removable media drives have write
protect tabs, I'd just like to find a drive under $1000 that'll do it.)

It was pointed out to me at a recent seminar, by one of the attendees who
had access to a bunch of old equipment, that very old hard drives for
PC's, based on mainframe models, did, indeed, have such a switch.

Anybody wanna sell a really old drive?  :-)

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Fri, 23 Aug 91 10:51:27 -0700
>From:    [e-mail] (Rob Slade)
Subject: Can virus infect PC data diskettes? (PC)

[e-mail] (Steve Masticola) writes:

> 1. Can a virus infect data diskettes and propagate from them (possibly
> by rewriting the boot track)?

Yes, boot sector infectors, such as the Stoned, BRAIN, Joshi, Azusa etc.,
do exactly this.  All disks have a boot sector, and therefore all disks
can be infected, even if they have no programs on them, and even if they
are not "bootable".

> 2. Can viruses infect data files (not executables) downloaded from
> BBSes?

In the Macintosh world this has already happened.  Hypercard contains a
"language" which can be extended to perform system level activities, and
Hypercard "stacks", which are basically data, have been made to contain
viral functions.  In the PC world this has not, to my knowledge, been
done, but it is quite possible with the right systems.  Any program which
has a scripting or macro language is a possibility.

> Also, if someone has a pointer to an archive with info about PC

I have all of my articles archived on the SUZY system, and soon on
Cyberstore as well.

> viruses (in plain text), or good magazine articles, I'd appreciate
> knowing that, too.

We'd *all* love to know that.

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Fri, 23 Aug 91 10:58:07 -0700
>From:    [e-mail] (Rob Slade)
Subject: Bad hit on KENNEDY/12 Tricks Trojan?? (PC)

As you stated, the version of VIRUCIDE that you first tested is an
older one.  And, both SCAN and VIRUCIDE are written by McAfee
Associates.  As I believe they stated, when the issue was raised
before, both programs contain the same "signature strings".  Because
the signature strings are contained within the program code, SCAN sees
VIRUCIDE as being infected.

They fixed this in the later version of VIRUCIDE.

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    Fri, 23 Aug 91 20:58:51 +0000
>From:    [e-mail] (CAD Group Guest Accoun
      t)
Subject: RE: where is VSUM9108.ZIP or TXT

|> ============================================================================
|>                       HyperText VSUM X9107 READ_ME.1ST
|>
|>      With the June, 1991 release, the Virus Information Summary List
|> has been converted from its original ASCII list format into a custom,
|> hypertext database format.  With the new format, the product name has
|> been changed to HyperText VSUM.  The previous ASCII list product has
|> been discontinued, and will no longer be updated.
|>
|>      Why the change to a hypertext database?  The original ASCII format
|> had become extremely large and unwieldy, it was difficult for most
|> people to effectively use.  Printing also had become a problem unless one
|> had a very high speed laser printer.  More importantly, the information
|> presented in the ASCII version was never really intended to be read
|> sequentially as a book, but instead to be a reference book or
|> encyclopedia.
|> ============================================================================
=

But what is hypertext? Is it a shareware/freeware product? If yes,
where can I get it?

    Thanks,
        Nadav Har'El

------------------------------

Date:    23 Aug 91 17:16:24 +0000
>From:    attcan![e-mail] (Richard Meesters)
Subject: Re: Double quote char appear all over - virus? (PC)

[e-mail] (Thomas Wong) writes:
> One of the 386s in our lab has been having a strange problem.  Double
> quote characters slowly appears all over the screen.  I've checked the
> computer with VirusScan (SCAN 7.6V80)(latest?)  and no virus was
> found. Has anyone seen this before? How can I tell if this is a new
> (yet to be discovered) virus? What to do?  What to do....

It's completely possible that there's no virus at all.  Does the
machine lock up when this happens?  My thoughts would be that if the
SCAN package doesn't detect the virus, you should have someone look at
your video hardware (the video card, in particular).  I've seen cards
go bad in such a way that they print spurious characters over the
screen (usually bad video memory/decode).

Hope this helps,
Regards,

- ------------------------------------------------------------------------------
     Richard A Meesters                |
     Technical Support Specialist      |     Insert std.logo here
     AT&T Canada                       |
                                       |     "Waste is a terrible thing
     ATTMAIL: ....attmail!rmeesters    |      to mind...clean up your act"
     UUCP:  ...att!attcan!ram          |
- ------------------------------------------------------------------------------

------------------------------

Date:    Sun, 25 Aug 91 13:21:59 +0000
>From:    [e-mail] (Yaron Bloom)
Subject: Can a virus be LAGAL?!

Since I'm quite interested in the subject, I wanted to ask if a virus
can be lagal. I now every country has it's own rules, but I haven't
heard of a law agains viruses, have you?  One more point: Viruses may
be thought as a way of corrupting other user's data. But what about
software piracy? If one copies hacked software, then why shouldn't
viruses hit him?

 I'd like to hear you comments.

   Yaron Bloom            [e-mail]

------------------------------

Date:    25 Aug 91 00:37:48 -0400
>From:    Robert McClenon <[e-mail]>
Subject: Re: Bad hit on KENNEDY/12 Tricks Trojan?? (PC)

Eric N. Lipscomb writes:

>OK.  Here's a good one. . .
>
>For whatever reason, one of our Business Profs decided to scan the
>copy of VIRUCIDE on his hard disk, and lo and behold, SCAN 5.3C67
>finds Kennedy and 12 Tricks Trojan in VIRUCIDE.EXE.  VIRUCIDE,
>scanning itself, finds nothing.  SCAN also tells us that the file is
>compressed with LZEXE and is infected internally.  Hmmmm.
>
>it seems to me that McAfee SCAN is giving a false positive on the
>Kennedy virus in VIRUCIDE.  VIRUCIDE (another, later version that
>scanned clean by everything we threw at it) and F-PROT don't identify
>anything.  And an old version of SCAN identified the 12 Tricks Trojan.
>Unfortunately, I don't have any other disk scanners laying around that
>I can check it against.  But our techies are looking a little more
>closely into this suspicious disk write behaviour exhibited by the
>suspect VIRUCIDE.
>
>Any thoughts/ideas from the list at lagre, specifically the McAfee
>crew (since both SCAN and VIRUCIDE came from McAfee)?  This is
>certainly something that our University will take into serious
>consideration as talks finalize on which product to go with as a
>campus standard.

There have been previous reports to Virus-L of false positives where
one anti-viral package identified another as being infected.  In
particular, reports of SCAN saying that VIRUCIDE might be the 12
Tricks Trojan have been common.  These reports are indeed false
positive.  There is a simple reason for these false positives.  An
anti-viral scan package looks for virus signature strings.  Another
anti-viral package may legitimately contain the same virus signature
strings.  These false positives would be even more common except that
some anti-viral packages conceal the signature strings by encryption.

False positives where one anti-viral package says another is infected
are common, and are caused by finding a signature in the signature
search code.

------------------------------

Date:    Sun, 25 Aug 91 23:08:20 +0000
>From:    [e-mail] (McAfee Associates)
Subject: Re: Bad hit on KENNEDY/12 Tricks Trojan?? (PC)

[e-mail] (Eric N. Lipscomb) writes:
>OK.  Here's a good one. . .
Okay

>For whatever reason, one of our Business Profs decided to scan the
>copy of VIRUCIDE on his hard disk, and lo and behold, SCAN 5.3C67

(the current version of VIRUSCAN is V80)

>finds Kennedy and 12 Tricks Trojan in VIRUCIDE.EXE.  VIRUCIDE,
>scanning itself, finds nothing.  SCAN also tells us that the file is
>compressed with LZEXE and is infected internally.  Hmmmm.

This problem is due to an old version of VIRUCIDE containing the same
strings as VIRUSCAN and has been corrected for quite a while.  I don't
remember the version of VIRUCIDE it was fixed in, but I believe it was
2.1x or 2.2x.  The current version of VIRUCIDE that Parsons' Technology
is shipping is 2.30.  They've got new packaging with a picture of what
looks like a beetle on the cover.

>Next step, we run SCAN 6.3V72 on VIRUCIDE.EXE, and the Kennedy virus
(still an old version of VIRUSCAN :-) )

>reveals itself again, but not the 12 Tricks Trojan.  Hmmm.  Next step,
>run the latest release of SCAN.  Bingo, it finds Kennedy.  All
>versions of SCAN that we throw at it find Kennedy and tell us that the
>file is LZEXE compressed.

Well, one out of two isn't bad.  It is compressed with LZEXE.

>Now, a bit of info about VIRUCIDE: the file is 40209 bytes long, dated
>5-8-90.  It appears to the user to be functioning properly, and even

A really old version of VIRUCIDE.  Last time I looked at it, it was around
60 or 80Kb long...

>though SCAN says it's infected, nothing *apparently* happens to the
>system as a result.  However, one of our techies is looking at the
>execution of the program, and has found that as VIRUCIDE scans a file,
>it also attempts to perform a write to side 0 track 0 sector 6, thus
>far unsuccessfully.  One of the strings it attempted to write was
>"Disk Killer".  Hmmmmm.

Hmm... VIRUCIDE shouldn't write to the disk, are you sure you aren't running
any other TSR anti-viral programs?

<paragraph about F-PROT not finding anything deleted here>
>Now, except for the suspicious attempts to write to the boot sector,
>it seems to me that McAfee SCAN is giving a false positive on the
>Kennedy virus in VIRUCIDE.  VIRUCIDE (another, later version that
>scanned clean by everything we threw at it) and F-PROT don't identify
>anything.  And an old version of SCAN identified the 12 Tricks Trojan.
>Unfortunately, I don't have any other disk scanners laying around that
>I can check it against.  But our techies are looking a little more
>closely into this suspicious disk write behaviour exhibited by the
>suspect VIRUCIDE.

This is one of the subjects that continually comes up in comp.virus, so
let me reiterate it, at the possible expense of wasting bandwidth and
boring one or two of you:  It's always a good idea to have the latest
version of anti-viral software available, and not rely on old, outdated
versions which may have compatibility problems of some sort or another.
Keep a copy of the last release on a floppy or somewhere safe as a backup
in case problems are reported and you need to migrate back to an older
version, but still, try to keep up to date and watch the network or the
manufacturer's BBS, fax, etcetera for notices of bugs in the software or
announcements of new releases...

>Any thoughts/ideas from the list at lagre, specifically the McAfee
>crew (since both SCAN and VIRUCIDE came from McAfee)?  This is
>certainly something that our University will take into serious
>consideration as talks finalize on which product to go with as a
>campus standard.

Most of the comments are above :-)

>Thanks for your time!

Welcome.

Aryeh Goretsky
McAfee Associates Technical Support

- --
McAfee Associates     | Voice [phone]    | [e-mail]  (business)
4423 Cheeney Street     | FAX   [phone]    | [e-mail](personal)
Santa Clara, California     | BBS   [phone]    |
95054-0253  USA         | v.32  [phone]    | CompuServe ID: 76702,1714
ViruScan/CleanUp/VShield | HST   [phone] | or GO VIRUSFORUM

------------------------------

Date:    26 Aug 91 08:46:53 -0700
>From:    [e-mail]
Subject: 4096 help needed (PC)

Hello

  My PC is inficted by 4096 virus. I remove it by clean software but it
  returnd back. Can anybody send me some information about it and
  how remove it.

  Thanks

  Fuad B.
  King Abdul Aziz University
  Saudi Arabia - Jeddah

------------------------------

Date:    26 Aug 91 10:13:59 +0000
>From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Ghosting

[e-mail] (A. Padgett Peterson) writes:

>    Vendors face the problem that while most viruses are
>relatively easy find in a program (commands are usually found at
>specific offsets), in memory the viral signature could be anywhere
>(well, almost anywhere) in memory. We are starting to see products
>that are more specific about where they look but while some viruses
>will only inhabit certain locations, others could be anywhere in RAM,
>high or low.

Well, almost all of the currect memory resident viruses contain their
signatures at a fixed offset of a paragraph boundary. You have only to
scan memory in 16-byte paragraphs and to check whether the signature
is at the known offset. This speeds up the things. Unfortunately,
there are still viruses like Whale that use run-time sliding window
encryption, but they are rare enough.

Anyway, the problem with "ghosting" has occured with files long time
ago. Some scanners still cause false positives because they find the
signature that another anti-virus program also uses. Fortunately, now
most self-respecting scanners use some kind of encoding (not
encryption!) and solve such problems. How much have we to wait, until
these scanners also clean up the memory they have used before exiting?

>    In any event, as the number of viruses (and signatures)
>continue to increase and the avaialble signatures decrease, it would
>not be surprising to see the tendancy for ghosting as a result of
>using multiple products to increase.

IMHO, ghosting will decrease in the near future, because those that
make scanners sill become aware of it and will take measures against
it.

>    Meanwhile, we still have the second of the two causes of
>ghosting to account for: the "disinfected" file.

>    Here we have an oddity of DOS at work, the cluster. Consider a
>2k .COM file that contracts the Jerusalem (1808 bytes) virus. Many
>older machines with 32 Mb disks use a 4096 byte (4K) cluster size.
>This is the minimum disk quanta that DOS can allocate so the original
>file occupied 1 cluster (the minimum). Not surprisingly, the infected
>file also occupied 1 cluster, just filling more of it.

>    When the virus disinfectant came along, chances are that it
>just removed the virus vector at the start of the program, replaced
>the first few bytes with the ones from the original file that the
>virus stored, and adjusted the file size. The virus is now
>disconnected and the code following the program is just noise.

Yeah, the same problem occures when someone browes such a disinfected
program with PCTools or Norton Utilities. I kept getting quiestions
like "why after disinfecting Dark Avenger with your program I still
can see the 'Eddie lives' message in files?", until I began to
overwrite the virus body with zeroes before disconnecting it from the
file. Now I think that every disinfector should perform this way,
regardless which virus is disinfected...

>    However, unless the viral code is stripped off manually, it is
>still there and when the program is executed next, the whole cluster
>is mapped into memory and often into the disk buffer (though these
>generally have a finer granularity). If the program was larger than
>the scanner that runs next (obviously not in the example) or goes TSR,
>guess what is liable to happen ?

Well, I still cannot understand why a scanner should look for, say,
the Dark Avenger virus in DOS' buffers! McAfee's SCAN causes a ghost
false positive immediately after you copy an infected file...

Regards,
Vesselin

------------------------------

Date:    Mon, 26 Aug 91 09:10:00 -0400
>From:    [e-mail]
Subject: The Wisconsin Virus???!!! (PC)

HELLO, has anybody out there heard of the Wisconsin virus on the IBM
and compatibles?  It showed up on one of our PC's here at Pitt and our
Virus scan software would not remove it.  We have version 6.8B74 of
Virus Scan.  Is this the latest version?

The only thing it does so far as I can see is it freezes up the PC and
it must be rebooted.  Please reply if you know anything about this
virus.

Thank you.

Chris Kunselman

------------------------------

Date:    26 Aug 91 09:26:28 +0700
>From:    Pim Clotscher <[e-mail]>
Subject: EICAR & CARO adresses needed

Please could somebody out there in free netspace tell me the
addresses, telephone numbers and E-mail addresses of EICAR and CARO?
They are virus security an -research centres is n't it? What exactly
stand the digits E.I.C.A.R. and C.A.R.O. for?? I remember to have read
info about these organisations on this list in the past, but I skipped
it that time...

Thank you very much,

- ----------------------------->  Pim Clotscher  <------------------------------
                        Erasmus University Rotterdam
                     E.R.C. - Computer Support Hoboken
                             Roomnumber : Ee2067
Dr. Molewaterplein 50                                            P.O. Box 1738
NL-3015 GE  Rotterdam                                     NL-3000 DR Rotterdam
                                                               the Netherlands
Tel: [phone]
Fax: [phone]           E-mail (Internet):   [e-mail]
==============================================================================

------------------------------

Date:    Fri, 23 Aug 91 18:32:52 +0000
>From:    [e-mail] (Doren Rosenthal)
Subject: Virus Simulator available (PC)

     --------------------------------------------------------------------
         Virus Simulator - Safe and Sterile Virus Security Validation
     --------------------------------------------------------------------

   Virus   Simulator  version  2.0  is  now  available  as  shareware   for
   downloading from several sources including EXEC-PC (VIRSIM20.COM),  SLO-
   Bytes  BBS  (805)  528-3753  and Compuserve  (VIRSM2.COM),  as  well  as
   directly from the author.

   Virus   Simulator  generates  controlled  programs  infected  with   the
   signatures  (only)  of  every  known  virus  available.  Because   Virus
   Simulator  has  ability  to  harmlessly compile  and  infect  with  safe
   viruses,  it  is valuable for demonstrating  and  evaluating  anti-virus
   security  measures  without  harm or contamination of  the  system.  The
   infected  programs  can  be  renamed  and  copied  to  other  disks  and
   directories as bait for virus detecting programs.

   Viruses  are  a  form  of  terrorism  and  require  many  of  the   same
   precautionary  measures.  Airports  test  the  effectiveness  of   their
   security  measures  in  much the same way. An official  disguised  as  a
   passenger will attempt to bring a disarmed bomb through, trying to evade
   security   measures  and  avoid  detection.  Real  viruses,  like   real
   terrorists,  are  much  more difficult to test with.  The  test  viruses
   generated by Virus Simulator are safe and sterile, but form a validation
   test suite that trigger vigilant virus detectors.

   Virus  Simulator  creates simulated test suites for  every  known  virus
   available  at the time of release.  These test suites are only safe  and
   sterile  simulations  to  evaluate  your  security  measures.  A   virus
   detecting  program is validated when it reports the  simulations.  Virus
   detecting  programs  that  fail to find  these  simulations  may  indeed
   discover  their  real counterparts and variations, but  should  only  be
   trusted after that ability is demonstrated.

   No  virus  protection  program  will  ever  be  effective  without   the
   cooperation of its users, and Virus Simulator provides a means to verify
   compliance with established security procedures.

   System  Administrators should design their own tests to see which  users
   are practicing safe computing and complying with established safeguards.
   The  amount of user cooperation required by anti-virus programs  varies.
   Some  users require more automatic and regimented procedures, and  Virus
   Simulator  provides  system  administrators  with  a  practical  way  to
   evaluate  the  overall effectiveness of their security  measures.  These
   simulated  test viruses are sterile; they won't reproduce and spread  by
   themselves, so they have to be planted (copied). Such an exercise can go
   a long way to raising the vigilance of complacent users, so when a  real
   virus attacks, destructive damage is held to a minimum.

   Comments  and  suggestions  are  would  be  appreciated  and  should  be
   addressed directly to:


   Doren Rosenthal               Phone [phone]
   Rosenthal Engineering
   3737 Sequoia
   San Luis Obispo, CA 93401 USA

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 148]
******************************************
VIRUS-L Digest   Tuesday, 27 Aug 1991    Volume 4 : Issue 149

Today's Topics:

Re: Hard disk locking ? (PC)
Polish anti-virus group info
CPAV + SCAN conflict (PC)
Re: Hardware and software protection mechanisms
Re: Self-scanning executables (PC)
Re: Can a virus be LAGAL?!
Re: Hard disk locking (PC)
Scan Memory (was: Questions regarding Novell, Viruses & policy)
Re: CARO / EICAR address
Re: copyright of infected files
Re: Ghosting
Preventing boot from floppy - problem with Int 13 from TSR (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Tue, 27 Aug 91 11:49:00 +1200
>From:    "Mark Aitchison, U of Canty; Physics" <[e-mail]>
Subject: Re: Hard disk locking ? (PC)

[e-mail] (Rob Slade) writes:
> I have long decried that fact that hard drive manufacturers still have
> not thought to include a cheap and simple write protect switch on hard
> drives.  (Yes, I do know that most removable media drives have write
> protect tabs, I'd just like to find a drive under $1000 that'll do it.)

I agree.

> It was pointed out to me at a recent seminar, by one of the attendees who
> had access to a bunch of old equipment, that very old hard drives for
> PC's, based on mainframe models, did, indeed, have such a switch.

Well, I've got a 12.5Mb disk drive with a write-protect switch. It
also has a switch that (from memory) makes either the hard disk or the
floppy drive the bootable drive. Apart from the fact that it is a 19"
rack-mounting monstrosity, and designed to run on a Data General
minicomputer, I'd be happy to sell it to you ;-)

Seriously, how come modern manufacturers *uninvent* features that were
presnt on minicomputers a decade or two ago?? I am interested in
security, not only against viruses and fiddling, but against
breakdown; it seems that old ideas of dual porting and watchdog timers
and so on have gone, yet the need for them is at least as great.

When the computer was in one, big room, it was easy to make it
physically secure and control its environment. The present discussion
of "absolute security" being impossible with software-only measures,
although having some merit, should consider the difficulty in
attaining such high ideals in the typical pc workplace. A
write-protect switch, or a card that can be removed, is not absolute
protection, and people should not be given any false sense of
security. If you know the situation well enough, you might be able to
say that such things are "good enough" - but in some situations a
software-only solution might also be good enough. I agree that
hardware solutions are basically better, of course, and they should be
built into the hardware rather than provided as add-ons, but it is
important to avoid crediting hardware solutions with too much security
when anyone could lift the lid and flick a switch or replace a card.

In the mean time, the best way to stop anyone putting a virus on your
computer is to stick a write-protect tab on the magnetic surface of
the hard disk drive.  Okay, it stops *all* accesses to the disk, and
the surface is ruined when you take the tab off, but it is *absolute*
protection! ;-)

Mark Aitchison
(e-mail debates welcome)

------------------------------

Date:    Tue, 27 Aug 91 11:55:00 +1000
>From:    [e-mail]
Subject: Polish anti-virus group info

Has anybody heard of the "Polish Section of Virus Information Bank".
We have recieved a ;letter from them and would like to know more.

Any information would be appreciated.

Wayne Boxall
Computer Virus Information Group
Queensland University of Technology

P.S They seem to have a product called : PCvirus (disk magazine)

------------------------------

Date:    27 Aug 91 07:07:43 +0000
>From:    [e-mail] (Jesse Chisholm AAC-RjesseD)
Subject: CPAV + SCAN conflict (PC)

I was testing the CentralPoint Anti Virus package (CPAV) and found an
interesting interaction with McAfee SCAN.  If I run the full TSR in
the CPAV package, VSAFE, then they get along OK.  But if I run the
faster and simpler, VWATCH, then SCAN v80 complains about the
Pakistani/Brain virus being in memory.  I suspect this is a false
alarm from VWATCH holding in memory the patterns it is looking for
when programs run, and SCAN finds them.  I spent an hour checking my
entire system the first time I got that message.

- -jesse        [e-mail]
- --
| "Don't just do something, stand there!" | "Curiouser and curiouser!"
|              -- The White Rabbit        |        -- Alice

------------------------------

Date:    Tue, 27 Aug 91 05:39:30 -0400
>From:    Valdis Kletnieks <[e-mail]>
Subject: Re: Hardware and software protection mechanisms

>Date:    Fri, 23 Aug 91 01:02:00 +0000
>From:    William Hugh Murray <[e-mail]>
>
>....
>That having been said, there is still a kernel of truth here.  That is,
>hardware mechanisms may not be as vulnerable to software is as is other
>software.  On the other hand, the strength of hardware mechanisms is
>limited by the laws of physics, while software mechanisms can be made
>arbitrarily strong.

Actually, this last sentence is not *quite* true.  You *cannot* make a
software mechanism "arbitrarily strong" in the mathematician's sense -
this is an outcome of Godel's Theorem and the Turing Halting Problem.
Interested readers are referred to Hofstaeder's "Godel, Escher, Bach"
- - in particular, the sections of the Dialogues dealing with record
players and records that destroy them....

However, it *should* be noted that any "attack software" capable of
mounting a Godelian attack on a system would most probably be well
past the point of "economic return"...  So it is *quite* possible to
create a software mechanism that is "strong enough to resist any
plausible threat in production usage".

                                  Valdis Kletnieks
                                  Computer Systems Engineer
                                  Virginia Polytechnic Institute

------------------------------

Date:    27 Aug 91 10:54:27 +0000
>From:    hoptoad![e-mail] (Laura Creighton)
Subject: Re: Self-scanning executables (PC)

[e-mail] (Eric Vaitl) writes:
>    I started thinking about self scanning executables again.
>Unfortunately, it was way to easy to write myself a virus which gets
>around the whole damn thing. Here is what it does: When the victim
>program is activated, the virus gets control. The virus then totally
>removes itself from the program on the disk (remember, the victim's
>name is in the psp). The virus then hooks itself into the timer
>interrupt and the idle interrupt and goes tsr.  Two timer ticks later
>a flag is set and on the next idle interrupt the virus loads and
>executes the original program. Any self scanning the original program
>does won't find anything. About ten minutes after going tsr, the virus
>sets another flag. On a following idle interrupt, the virus attacks
>two .exe files in the hard disk. It then unhooks the interrupt vectors
>and returns it's saved memory to dos.
>    I'm not a real whiz at assembler programming and I was able to get
>this thing under 2k and write it over the weekend.

You are damn right, absolutely damn right.  That is the
way to write it and it seems close to impossible to detect.
That is how I wrote mine.

aside ----

remeber the big Internet Crash?

At the time it happened, I had just written such a program for Chevron
who hired me to demonstrate that no cracker could get in.  Instead, I
kept claiming that they were wide open.  So I wrote such a program,
and ran it on isolated ``secure'' systems to tell them that they had a
real damn actual problem here, and hiring me to cover it up wouldn't
work....

Bingo.  TV coverage of the Internet crash happens after I come home
from a theatre evening, and my first thought was, holy shit, this was
not what I was promised, an isolated non-internet community, and my
problem has spread to the whole damn Internet.  Oh hell! They will
barbq me and maybe jail me... oh shit....

And I phone around and discover that it is another, more simple minded
problem.

And life goes on, I convince Chevron, I get paid, all is happy....  I
needed to write a virus in order for them to see that they had a
problem.  But I trusted them that their machines were isolated.  I got
lucky, that was true.

But that is pure luck.

If you ever get to write a virus for a company make damn certain that
it is off the internet before you go to work.

I lucked out.

Don't make that mistake.

Laura

------------------------------

Date:    Tue, 27 Aug 91 12:52:17 +0000
>From:    [e-mail] (Terry N Reeves)
Subject: Re: Can a virus be LAGAL?!

[e-mail] (Yaron Bloom) writes:
>I haven't
>heard of a law agains viruses, have you?  One more point: Viruses may
>be thought as a way of corrupting other user's data.

Under the laws of the United States and many of the states within it,
viruses are illegal for exactly the reason stated - the alter the data
or programs of others.

Further comments about viruses being the just deserts of pirates are
ill informed at best. Many many people have been harmed by viruses
without being pirates. In any case punishment for copyright violation
is a matter for the courts not "progammmer-vigilantes"
- --
 _____________________________________________________________________________
|                   That's my story, and I'm sticking to it!                  |
|_____________________________________________________________________________|
| Public Sites micro software support |   [e-mail]   |

------------------------------

Date:    26 Aug 91 15:50:47 -0400
>From:    Jon Freivald <[e-mail]>
Subject: Re: Hard disk locking (PC)

>>It requests a password on boot (installs via config.sys).  If the
>>system is booted via floppy disk, the hard disk cannot be accessed
>>without running a special utility on the PC-Vault diskette (unlike a
>>couple other programs where you just plain can't access the hard disk
>>period!).
>
>As I wrote in one of my previous postings, it depends on what do you
>understand by "cannot". You probably mean that when DOS boots, it
>cannot recognize the disk (says "invalid disk drive" when you try to
>switch to that disk). This, of course, does not mean that the disk is
>not accessible to BIOS (using INT 13h, not INT 25h/26h). More
>exactly,
>this means that any boot sector virus that is able to infect MBRs
>(Master Boot Records - where the partition table resides), will be
>able to infect a disk "protected" in this way.
>
>Such protection schemes usually install themselves in the MBR, then
>either encrypt the partition table, or move the original MBR to
>another place. If a virus attacks such disk, it will just install
>itself in the MBR and move the MBR, containing the protection program
>to another place. When the computer is booted, the virus receives
>control, stays resident in memory, then reads the moved MBR and
>transfers control to it. Since the protection program resides there,
>it will just ask for the password and so on.
>
>Since all MBR infectors use BIOS to access the disk, there is no
>possibility to "hide" the disk from them. It is possible, however, to
>disinfect the disk automatically on reboot, but this is another
>story.

You are indeed correct.  I was answering in the same context as I
percieved the question to have been asked - that of keeping an
"average" user from "borrowing" the system.  My brother proved to me
that someone who knows what he's doing can circumvent it in well under
an hour (I think he got in - actually booting from the HD - in about 12
minutes or so...), however, I run a 165 user LAN & it stops them *all*
dead in their tracks...  Good enough for the intended purpose.

Yes, I should be much more careful about using words like "can't" in a
conference that attracts so many technically proficient people.  (When
I was working as a machinist the easiest way to get a project out of me
was to insinuate that I couldn't do it with the equipment at hand...!)

Chastisement accepted constructively...

Regards,

Jon


------------------------------

Date:    27 Aug 91 11:13:20 -0400
>From:    "David.M.Chess" <[e-mail]>
Subject: Scan Memory (was: Questions regarding Novell, Viruses & policy)

>Date:    Thu, 22 Aug 91 15:16:11 -0400
>From:    [e-mail] (A. Padgett Peterson)

>* - At present I know of no virus scanner other than McAfee's that can
>scan memory only for resident  viruses  (and he does not document it).
>The CHKHI switch for high memory is a recent addition.

The IBM Virus Scanning Program can do that: "VIRSCAN -MEM" to scan
only memory for only the dangerous viruses, or "VIRSCAN -MEM -G" to
scan only memory for all viruses.

DC

------------------------------

Date:    Tue, 27 Aug 91 17:17:17 +0600
>From:    [e-mail]
Subject: Re: CARO / EICAR address

Hi, here are infos you requested:

   CARO = Computer Antivirus Research Organisation
     This is a group of researchers
     at present there are:
         Vesselin Bontschev (used to be Academy of science in Sofia,
                             now University of Hamburg)
         Christoph Fischer (University of Karlsruhe Micro-BIT Virus Center)
         Fridrik Skulason (University of Reykjavik)
         Morton Swimmer (University of Hamburg)
         Michael Weiner (University of Vienna)

   EICAR = European Institute of Computer Antivirus Research
         The above members and a couple of other people will found
         this officially on 23rd of September during the European Conference
         on computer viruses in Brussles 24th to 25th of September.
         This is an industry, science, and user organisation.

   The address of the secretariat will be in Belgium. As an interim solution
   you might contact any of the above institutions.
   More will follow after the officiall founding.....
   A invitation to the conference will be posted as soon as I have the final
   text.
   Sincerely
      Christoph Fischer


Christoph Fischer
Micro-BIT Virus Center
University of Karlsruhe
Zirkel 2
W-7500 KARLSRUHE 1
Germany
[phone] Phone
[phone]  FAX
email: [e-mail]

------------------------------

Date:    Mon, 19 Aug 91 20:05:16 -0600
>From:    [e-mail]
Subject: Re: copyright of infected files

[e-mail] (Warren Burstein) writes:
>It occurred to me that anyone who deals with viruses must of course
>have a collection of infected files for comparison, dissasembly, and
>testing of anti-viral methods.  It would not be surprising for such
>people to thereby acquire lots of copies of software that they don't
>have licenses for (and what if the virus has a copyright, too :-) ?).
>Not that they ever intend to use the software for its intended
>purpose, but might the manufactures get upset anyway?

An interesting point. The manufacturers would certainly be upset if
this person were to distribute a) illegal, and b) infected copies of
their software. If he contributed to the safer use of the
manufacturers software through his having an infected copy, I think it
quite unlikely that they would charge him with copyright infringement.

Copyrighted viruses?! Actually, the sort of person who gets his
jollies inflicting the rest of the world with his ego, just _might_ be
stupid enough to try to charge those infected with having illegal
copies. It would make an interesting plot for a novel, but I don't
think we'll see it in the news.

- -------------------+-------------------------------------------
Al Dunbar          |
Edmonton, Alberta  |  Disclaimer: "not much better than
CANADA             |                  datclaimer"
- -------------------+-------------------------------------------

------------------------------

Date:    Tue, 27 Aug 91 13:03:30 -0600
>From:    [e-mail] (Tim Martin; FSO; Soil Sciences)
Subject: Re: Ghosting

    A few previous postings have talked about the "ghosting"
effect some scanners cause: false positives because of remnants
of viruses on disk or in memory.  I had an interesting experience
with this effect recently.

    At U of Alberta we have been installing DiskSecure and FPROT
in all our computer labs.  When we added an "f-disinf" line to
our autoexec.bat file, a couple computers reported an infection
by the Empire virus, on boot-up.  This seemed odd, since DiskSecure
was already in place, and CHKSEC had reported that DiskSecure was
working ok.  On inspection, we found that what we were seeing was
a ghost effect:

    DiskSecure was in its proper place in sector 1.  DiskSecure
had properly copied the "real" partition table to its favorite hiding
places.  But these couple stations previously had had an infection by
the empire virus, and the main partition table had been rebuilt (months
ago) using Norton Disk Doctor.  NDD puts the partition table code and
error statements into place, and builds the table, but leaves the
remaining bytes of the sector (almost half the sector) unchanged.  So
the remnants of Empire were still to be seen in these remaining bytes.

     On boot-up, DiskSecure was working, so when f-disinf asked to see
the main partition table, DiskSecure showed it (using stealth) the
"clean" main partition table, which still had a few remnants of
the Empire virus in it.  My complements to Frisk: f-disinf caught these
remnants (despite the fact most of them were randomly encrypted) and
recognised an "infection" present.

     A ghosting error like that is one I am quite willing to live with. It
suggests Frisk is using a good scan string. And it re-affirms Padgett's
continual contention, that general users should use virus detection tools
to trigger a warning, then get competent technical help in to do the
testing / clean-up.  Third observation you might have made: using
"f-disinf c:" in the autoexec.bat on a DiskSecure-protected computer
is not terribly useful, given DiskSecure's "stealth" techniques.  Except
maybe for finding this kind of a ghosting effect!

Tim Martin
University Of Alberta
** The opinions expressed are my won: my employer has none **

------------------------------

Date:    Tue, 27 Aug 91 15:28:03 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: Preventing boot from floppy - problem with Int 13 from TSR (PC)

Having finally found some free time, I started looking at a "kill
floppy boots" TSR. The criteria was to:
     1: Trap cntrl-alt-del sequence
     2: Check for floppy in drive A:
     3: Disallow boot if floppy in drive
     4: Provide separate mechanism for a maintenance floppy boot
        (cntrl-alt-F)

The code itself is not difficult and takes up about 800 bytes  as
a TSR (0 impact with DiskSecure) but I ran into a glitch with the
floppy detection sequence. The code used looks like this:
(see Ray Duncan's BIOS book in the description of INT 13 fn 04)

     MOV SI, 0003   ;try three times
LP1: MOV AX, 0401   ;verify one sector
     MOV CX, 0001   ;sector 1, head 0
     MOV DX, 0000   ;track 0, drive 0 (BR floppy A)
     INT 13
     JNC XXX        ;NC = floppy in drive. C = access failed
     DEC SI         ;(try three times with reset before each retry)
     JZ  YYY        ;ZR = assume no floppy in drive
     XOR AX,AX      ;reset drive
     INT 13
     JMP LP1

(code simplified for readability but does the essentials).

The problem is that this works just fine when run as  a .COM  but
as  soon  as it is installed TSR & invoked  from  a  ctrl-alt-del
sequence, it runs bog sloooow & is not always accurate. This  was
reproducable  both  on  an 8088/DOS 3.3 and a  386/DOS  5.0.  The
question  is,  does anyone know why & how to fix ?  I  know  that
eventually  a  workaround can be found but can't spend a  lot  of
time  on it. Once the One True Answer is found, the TSR  will  be
posted as FreeWare.
                            Padgett

386 the .COM runs in 1-3 seconds. When TSR  it takes 10-13
    seconds. I assume (you know what that  means) that some  kind
    of additional setup is necessary & done by DOS for a .COM
ps: thought  of floppy door flag but it is not necessarily set or
    universally used.

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 149]
******************************************
VIRUS-L Digest   Wednesday, 28 Aug 1991    Volume 4 : Issue 150

Today's Topics:

Re: Hard disk locking ? (PC)
RE: where is VSUM9108.ZIP or TXT
Bad hit on KENNEDY/12 Tricks Trojan?? (PC)
Re: Hard disk locking ? (PC)
Re: Polish anti-virus group info
Re: CPAV + SCAN conflict (PC)
Re: CARO / EICAR address
Norton reports "Italian" - help (PC)
Drive assignments... (PC)
CAPV conflict with FPROT116 (PC)
Ten Bytes False Positive with VIRX fixed (PC)
Re: CPAV + SCAN conflict (PC)
Dark Avenger'r mutating engine (PC)
NoFBoot (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].

   Ken van Wyk

----------------------------------------------------------------------

Date:    Tue, 27 Aug 91 17:43:44 -0400
>From:    [e-mail] (A. Padgett Peterson)
Subject: Re: Hard disk locking ? (PC)

>[e-mail] (Rob Slade) writes:
> I have long decried that fact that hard drive manufacturers still have
> not thought to include a cheap and simple write protect switch on hard
> drives.  (Yes, I do know that most removable media drives have write
> protect tabs, I'd just like to find a drive under $1000 that'll do it.)

I understand the vendors, disk drives are  hidden inside the  case and
would require some extra hardware  to do what  you ask.  Nowadays they
are cutting costs to the penny. All is not lost however:

Seems to me that on a standard MFM or RLL drive, lead 6 on  the 34 pin
cable is the WRITE  ENABLE NOT lead.  I forget what  the logic is  but
seem to remember  that if  you   tie  6 to a  logic  "1" (+5 vdc  most
likely), the disk never permits writes. Some  experimenting and a dpst
switch should prove effective and cost less than U$1.00.

                                             Padgett

             "The clockwork on the inside goes"

------------------------------

Date:    Tue, 27 Aug 91 16:31:05 -0700
>From:    [e-mail] (Rob Slade)
Subject: RE: where is VSUM9108.ZIP or TXT

[e-mail] (CAD Group Guest Accoun) writes:

> But what is hypertext? Is it a shareware/freeware product? If yes,
> where can I get it?

Hypertext is more of a concept, sort of like "information processing"
or "spreadsheet".  What is meant is that you should be able to quickly
access related information in order to explain a concept of term you
find.

In the case of VSUM, it is going a bit far to call it hypertext, but
the information is now in data base format rather than the earlier
"plain text".  The reader program is included in the .ZIP file.

By the way, I thought that "beach" had posted VSUMX107.ZIP, but when I
went to look for it, no luck.

=============
Vancouver          [e-mail]   | "If you do buy a
Institute for      [e-mail] |  computer, don't
Research into      (SUZY) INtegrity         |  turn it on."
User               Canada V7K 2G6           | Richards' 2nd Law
Security                                    | of Data Security

------------------------------

Date:    27 Aug 91 23:26:09 -0400
>From:    Robert McClenon <[e-mail]>
Subject: Bad hit on KENNEDY/12 Tricks Trojan?? (PC)

Eric N. Lipscomb writes:

>OK.  Here's a good one. . .
>
>For whatever reason, one of our Business Profs decided to scan the
>copy of VIRUCIDE on his hard disk, and lo and behold, SCAN 5.3C67
>finds Kennedy and 12 Tricks Trojan in VIRUCIDE.EXE.  VIRUCIDE,
>scanning itself, finds nothing.  SCAN also tells us that the file is
>compressed with LZEXE and is infected internally.  Hmmmm.
>
>it seems to me that McAfee SCAN is giving a false positive on the
>Kennedy virus in VIRUCIDE.  VIRUCIDE (another, later version that
>scanned clean by everything we threw at it) and F-PROT don't identify
>anything.  And an old version of SCAN identified the 12 Tricks Trojan.
>Unfortunately, I don't have any other disk scanners laying around that
>I can check it against.  But our techies are looking a little more
>closely into this suspicious disk write behaviour exhibited by the
>suspect VIRUCIDE.
>
>Any thoughts/ideas from the list at lagre, specifically the McAfee
>crew (since both SCAN and VIRUCIDE came from McAfee)?  This is
>certainly something that our University will take into serious
>consideration as talks finalize on which product to go with as a
>campus standard.

There have been previous reports to Virus-L of false positives where
one anti-viral package identified another as being infected.  In
particular, reports of SCAN saying that VIRUCIDE might be the 12
Tricks Trojan have been common.  These reports are indeed false
positive.  There is a simple reason for these false positives.  An
anti-viral scan package looks for virus signature strings.  Another
anti-viral package may legitimately contain the same virus signature
strings.  These false positives would be even more common except that
some anti-viral packages conceal the signature strings by encryption.

False positives where one anti-viral package says another is infected
are common, and are caused by finding a signature in the signature
search code.

------------------------------

Date:    28 Aug 91 09:07:58 +0000
>From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Hard disk locking ? (PC)

[e-mail] (Mark Aitchison, U of Canty; Physics) writes:

>attaining such high ideals in the typical pc workplace. A
>write-protect switch, or a card that can be removed, is not absolute
>protection, and people should not be given any false sense of
>security. If you know the situation well enough, you might be able to
>say that such things are "good enough" - but in some situations a
>software-only solution might also be good enough. I agree that
>hardware solutions are basically better, of course, and they should be
>built into the hardware rather than provided as add-ons, but it is
>important to avoid crediting hardware solutions with too much security
>when anyone could lift the lid and flick a switch or replace a card.

I've heard about the existence of "physically secure" PC, which, when
you turn the key to lock the keyboard, also slide lids on their
screws, so you cannot open the computer (and unplug any cards), if you
don't have the key... Well, you just need a larger hammer... :-)

Regards,
Vesselin

------------------------------

Date:    28 Aug 91 09:20:08 +0000
>From:    [e-mail] (Vesselin Bontchev)
Subject: Re: Polish anti-virus group info

[e-mail] writes:

>Has anybody heard of the "Polish Section of Virus Information Bank".
>We have recieved a ;letter from them and would like to know more.

>Any information would be appreciated.

Yes, I know them. I know one of them (Andrzej Kadloff) personally and
have read some articles and have seen some disassemblies from Marek
Fillipiak. (Note: maybe the spelling of the names is not quite
correct, but I don't have them in front of me right now. If you are
interrested, I can try to find the exact spelling and the addresses.)
Maybe there are others, but I have heard only about these two guys.
Both are quite capable anti-virus researchers. Their disassemblies are
wonderful, although they have the bad habit to comment them in Polish
or in bad English... :-)

They have